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PREFACE 



The Network Operating System (NOS) is used with 
CONTROL DATA® CYBEH 170 Models 171, 172, 173, 
174, and 175 Computer Systems; CDC® CYBER 70 
Models 71, 72, 73, and 74 Computer Systems; and CDC® 
6000 Series Computer Systems. 

The NOS Batch User's Guide is an introduction to the use 
of NOS. It is intended for the applications programmer 
who is already familiar with a problem-oriented language, 
such as FORTRAN or COBOL, and wants to extend his 
capabilities by using the job-control statements of a full- 
scale operating system. NOS supervfees job processing in 
response to over 150 control statements. This guide 
explains a fundamental subset of about 50 statements. 
Only those parameters required for preliminary applica- 
tion are included. 

The descriptions in this guide are oriented to a data 
processing environment in which the user submits a job to 
a data center and has the job processed without concern 
for the mechanics of processing. AcecM-dingly, system 
{^eration and hardware functions are not mentioned 
unless a control statement requires identification of a 
software routine or a hardware feature. 



DISCLAIMER 

This manual describes a subset of the features and 
parameters documented in the NOS Reference Manual. 
Control Data Corporation cannot be responsible for the 
proper functioning of any features or parameters not 
documented in the reference manual. 



RELATED PUBLICATIONS 

This guide does not serve as an introduction to the 
programming languages used in the examples nor does it 



give the fundamentals of time-sharing operation in the 
description of batch jobs from a terminaL The langu^es 
and time-sharing operation are covered in the following 
manuals. 



Control Data Publication 

FORTRAN Extended 4 
Reference Manual 

COBOL 4 Reference Manual 

COBOL 5 Reference Manual 

BASIC 3 Reference Manual 

NOS Time-Sharing User's 
Reference Manual 



Publication No. 

60497800 
60496800 
60497200 
19983900 

60435500 



To enlarge on the fundamentals learned in this guide, the 
user ^ould consult the following manuals. 



Control Data Publicaticm 

NOS Reference Manual, 
Volume 1 

NOS Export/Import 
Reference Manual 

NOS Remote Batch Facility 
Reference Manual 



Publication No. 
60435400 
60436200 
60499600 



The preceding manuals contain references to other rel- 
evant manuals. 
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INTRODUCTION 



An operating system processes user jobs. The processing 
includes all activities associated with data proeessir^ 
(compiling and executing programs, formatting data, 
calculating, retrieving stored information, and preserving 
new information). A user job is a unit of work organized 
by the user to accomplish specific data prooessii^ tasks. 
Minimally, a job contains validation identification 
followed by a sequence of control statements that specify 
data manipulations to be performed by the system. 
Beyond this minimum, a job can contain programs and 
input for programs. 



MOTIVATION FOR THIS GUIDE 

Many jobs contain only j^ograms and program data. 
Although the user need know only a few control state- 
ments to get such jobs processed, a repertoire of control 



statements is more efficient. Single control statements 
can manipulate tape, create permanent files, copy data, 
reformat files, or initiate input/output (1/0) actions. 
Without control statements, the user must write a 
program every time he performs one or more of these 
operations. 



ORGANIZATION OF THIS GUIDE 

This gtiide is organized for instruction. It is intended for a 
user who writes pr(^ams in support of daily tasks but 
whose contact with an operating system has been the few 
control statements required for job processing. This user, 
to extend his knowlec^e in using system control state- 
ments, shoi^d become familiar with sections 2, 3, and 4. 
He can then eitha- select sections that serve immediate 
needs or systematically study the remaining sections. 
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The fundamental unit of data organization under N OS is a 
file. A user's interaction with the system is in terms of 
files. 

• The job the user submits for processing is a file. 

• Collections of data included with the job are 
transferred to the system in named packets; each 
packet is a file. 

• Control statements in the job can designate a 
name as a file; this is an empty file to which 
other statements or prc^ams can add data. 

• Control statements in a jcA> can copy all or part 
of an existing file; the copy is a file. 

• The output from job processing is a file. 



A file may be empty or as large as the user's resource 
limitations permit. 

The user can subdivide a file into logical records and he 
can link several files together into a multifile file. He 
does this subdividing either by means of parameters he 
includes in programs or control statements that create the 
files, or he can insert delimiters in the data he submits 
with a job (refer to Delimiters). 

"The user subdivides a file into records when he wants to 
access these subdivisions without accessing the entire file 
(for example, a master inventory is divided into parts 
categories). On the other hand, the user links several files 
into a multifile file when they fit into a single category he 
wants to access with a single reference (for example, 
student rosters from a number of classes are consolidated 
into CHie departmental roster). 

AU files are identified and accessed by a file name that is 
defined by the system or the user. This guide considers 
two system files, INPUT and OUTPUT (refer to INPUT 
and OUTPUT Files). The user names his file in the 
program or control statement that initiates its creation 
(refer to sections 3 and 4). A file name must be one to 
seven alphanumeric characters. 



DELIMITERS 

The user defines a file by assignii^ it a name and 
^jecifying the end of each record and the end of the file 
with delimiters. The user inserts delimiters directly or 
indirectly when he creates a file. He does this directly in 
the job he submits by inserting special punched cards (if 
the job L. a card deck) or typing in special directives (if 
the job is entered from a terminal). The fecial punched 
cards have three or four numbers multipunched in column 
1. The user creates these by depressing the MULT PCH 
key on the keypunch and, while it is down, entering the 
numbers. The user inserts delimiters indirectly by 
specifications he includes with control statements or 
programs. When the control statement is processed, the 
system puts the delimiters in the specified locations of 
the file being created. 

When a program is run, the system will place delimiters in 
files created by the program according to specifications in 
the program. 

The beginning of a file is called the beginning-of- 
information (BOD. BOI is internally recorded by the 
system when the file is created. No mark is put in the file 
by the system or the user; however, the user should be 
aware of its meaning since seva-al control statement 
descriptions refer to the SOL 

The user can delimit his files through end-of-record 
(SOR), end-bf-file~(EOF), and end-6f -information (EOI). 



END-OF-RECORD (EOR) 

The user inserts an EOR in a sequence of information to 
specify that all the information between this EOR and the 
previous terminator or BOI is to be accessed as a sii^le 
record. For a card deck, an EOR is a card with rows 7, 8, 
and 9 punched in column 1 (refer to figure 2-1). For a 
batch job submitted from a terminal with the SUBMIT 
cdntrol statement (refer to section 9), the user inserts an 
EOR by typing /EOR. 
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Figure 2-1. EOR Punched Card 
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END-OF-FILE |EOF) 

The user inserts an EOF in a sequence of information to 
specify that all the infopmation between this EOF and the 
previous EOF or BOI is to be considered a single file. For 
a card deck, an EOF is a card with rows 6, 7, and 9 
punched in column 1 (refer to figure 2-2). For a batch job 
submitted from a terminal with the SUBMIT control 
statement (refer to section 9), the user inserts an EOF bv 
typii^ /EOF. ' 



END-OF-INFORMATION |EOI| 

The user or the system adds an EOI to a sequence of 
information to specify that the entire sequence between 
the BOI and this EOI is to be referenced by the name 
assigned to this file or multifile. For a job punched on 
cards, the last card in the deck must be an EOI, a card 
with rows 6, 7, 8, and 9 punched in column 1 (refer to 
figure 2-3). For a batch job from a time-sharing terminal, 
the user does not have to designate an EOI. 



INPUT AND OUTPUT FILES 

The job input file is the system file containing the entire 
job the user submits for processing. Control statements in 
the job reference this file with the name INPUT. 

The job output file is the system file containing the output 
resulting from program execution and all the data copied 
to it by control statements. Control statements in the job 
reference this file with the name OUTPUT. 

The job input file is also known as a job file, and the job 
output file is also known as a print file or punch file. 

LOCAL FILES 

A locsd file has the following characteristics. 

• It is created by the job being processed. 

• It can be accessed only by that job. 

• It is no longer accessible when processing ter- 
minates. 
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Figure 2-2. EOF Punched Card 
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Figure 2-3. EOI Pur-ched Card 
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Since local files are available only to the job that creates 
them, they are said to be local to that job (refer to 
section 3). 



PERMANENT FILES 

The user can create and access files that remain in the 
system until they are specifically purged. They are 
distinct from local files, because their availability is 
independent of any job processing duration. Two types of 
pernianent files serve two types of needs, indirect access 
and direct access. Indirect access permanent files 
typically contain relatively small collections of data, and 
direct access permanent files typically contain larger 
collections of data. 



The user can create an indirect access permanent rile 
from a local file with special permanent file control 
statements. This file is accessed by retrieving the 
permanent file with special permanent file control state- 
ments (refer to section 5) to make a local copy of that 
file. 

The user can create a direct access permanent file by 
reserving an area on mass storage with the DEFINE 
control statement (refer to section 5) and then writing 
information in that area. Thereafter, the user can access 
the file directly with the ATTACH control statement 
(refer to section 5). 
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BATCH JOBS 



This section describes the types of t)ateh jobs, the 
structure of a batch job, the format of a control 
statement, and how programs are added to a job. The 
following control statements are explained in this section. 



job 


BASIC 


USER 


FTN 


CHARGE 


COBOL 


COMMENT 


COBOL5 



A programmer organizes a job with step-by-st^ instruc- 
tions that ^>eeify eyerythirg to be done in ^oee^ing the 
job. These instructions are the first record of the job. If 
he has programs to compile and execute, he may add these 
as additional records. If data input is required, he can 
supply this as additional records in the job or use 
instructions in the control statement record to reference 
existing ^les. Having organized the job, the ^c^ammer 
submits it for processing as a single unit without further 
intervention on his part. The next ttang he sees is the 
output from processing of the job. 

A job can be punched on cards or entered at a terminal. 
In either case, if the instructions and data are submitted 
as a complete unit and without further user intervention, 
they are claimed as a batch job. If the instructions are 
entered one at a time from a terminal with possible 
system/user interaction after each instruction, they con- 
stitute a time-sharing job (conversational batch). 



LOCAL BATCH 

A local batch job is punched on cards and submitted for 
processing via a card reader at the local computer site. 
Output is ordinarily routed to a local printer. Local batch 
is the assumed situation in the major portion of this guide. 



REMOTE BATCH 

A remote batch job is submitted for processing via a card 
reader at a remote batch terminal. Remote implies 
geographical separation of job submission and job proc- 
essing (refer to section 9). 

The system processes local and remote batch jobs 
similarly. Output from a remote batch job goes, by 
default, to the terminal from which it was entered. 
However, it can be routed to the local site where the 
computer is located. 



DEFERRED BATCH 

If a programmer creates a batch job at a time-sharing 
terminal by entering the statements as they would be 



punched on cards and then submits this sequence with a 
single command, the job is called a defen-ed batch job 
(refer to section 9). Output can be directed to a prmter 
or a file; it is not automatically displayed at the terminal. 
Submittii^ one batch job from another batch job is also 
called deferred batch (refer to the NOS Reference 
Manual, Volume 1). 



CONVERSATIONAL BATCH 

Conversational batch refers to the BATCH subsystem 
available under time-sharing job processing (refer to 
section 9). Under this subsystem, the terminal user can 
enter individual batch control statemente and Teeeive 
immediate execution of this statement. This use of t>atch 
control statements is classed as part of a time-sharing job 
and not a batch job. 



BATCH JOB STRUCTURE 

The user organizes his batch job according to the 
following requirements. 

1. The job must be identified. 

2. The user must be identified, t 

3. A charge number must be specified, t 

4. The entire job must be divided into records. 

5. The first record must contain all the control 
statements. 

6. The end of the job must be identified. 



A model batch j<* punched on cards is shown in figure 3-1. 
All the control statements, and only the control state- 
ments, appear in the first recM-d. A job may consist 
solely of this sii^le record of control statements. 

The first statement of the control statement recwd must 
be the job statement. If the installation has user 
validation, the second statement must be the USER 
statement. If the installation employs user accounting 
control, the third statement must be the CHARGE 
statem.ent. These statem.ents are explained later in this 
section. The remainder of the statements in the control 
statement record direct processing of the job. 

The records that follow the control statement record are 
programs and data. The data can be read by the prc^ams 
or by control statements. The program and data records 
must appear as they are referenced (refer to figure 3-1). 
The particular control statements shown are explained 
later in this guide. 



tThis is an optional installation requirement. It is the usual case. 
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THIRD RECORD 



SECOND RECORD 




6P/8iS card 

«nd-of-Jnformation 

7/8/9 card 
end-of-reeord (optional) 



DATA FOR PROGRAM 



FIRST RECORD 



CONTROL STATEMENTS 



Figure 3-1. Batch Job Representation 



CONTROL STATEMENT FORMAT 

Generally, a control statement can contain up to 80 
characters. OrdinarUy, it may begin in any column but 
must end by column SO. 

Most control statements t>egin with a name that suggests 
the nature of the operation to be performed (COPY, 
REWIND, SAVE). Exceptions are control statements 
beginning with an asterisk or a number. The asterisk 
signals a line of comment. Numbered control statements 
are explained in section 6. 

A control statement usually requires a parameter list to 
specify the file names, options, and numerical values 
which will be used in the operation the statement 
initiates. This list follows the control statement name on 
the same line. Separators must be inserted between the 
parameters. The fx-incipal separators are the following. 

. ( 

These separators can be used interchangeably unless a 
format requires a q>ecific separator. 

Spaces in a control statement are ordinarily ignored. 
Exceptions are the job statement and the USER statement 
which must not contain any spacing. 



The following examples are acceptable control state- 
ments. 



OSER(XXX.YYY) 
GET (CON T ROL ) 
CO PY, CONTROL 
REWIND , BETA , 



BETA ) 



The parameters included with a control statement are 
either order-independent (appear in any order) or order- 
dependent (must appear in a specified order). 

Parameters are order-independent if they are specified 
with a keyword. A keyword is an alphanumeric mnemonic 
with a defined meaning for the system. Some keywords 
have meanings by themselves; other keywords require the 
user to supply values (usually with an =). 

Parameters are order-dependent if they are user-supplied 
names or values whose application is identified by their 
location in the list following the control statement name. 
If an order-dependent parameter is omitted, the separator 
that would have followed it must be included. This is 
necessary so the system can match the remaining param- 
eters in the list with their appropriate application. If no 
parameters remain, the additional separator is not neces- 
sary. 
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A lew control statements auow order-independent and 
order-dependent parameters in the same list. In this 
format, the order-dependent parameters must come first. 
Some control statements have both an order-independent 
and an order-dependent version. In this guide, order 
dependency is ^ecified in the control statement descrip- 
tions. 

In many instances, the system will supply a default value 
for a missing parameter. TTiis will be the value commonly 
used for that parameter. Defaults of interest to the user 
are identified in the control statement descriptions. 

Every control statement must end with a terminatw on 
the same line. A terminator can be either of the 
following. 

) . 

Ejcamples: 

The operation of the following control statements is 
explained in later sections; however, the basic action is 
outlined to illustrate control statement format. 



The remainder of this section discusses the five principal 
control statements of a control statement record. 



JOB CONTROL STATEMENT 

A job statement or job card must begin every control 
statement record. TTiis statement identifies the job with 
a user-chosen name and, optionally, specifies a job step 
time Umit and/or maximum storage requiremert. The 
beginning batch user need only be concerned with ^>ee- 
ifying the name. The remainir^ parameters and job step 
definitions are explained in the NOS Reference Manual, 
Volume 1. 

The basic format of the job statement is as follows: 

jobname. 

jobname A 1- to 7-character user-chosen 
alphanumeric job name which must 
begin with a letter. 



The following is an wder-dependent control ^atement. 

C0PYBR{INPUT,MYFILE,1) 

This copies <Mie recwd from the INPUT file to a 
user-created file, MYFILE. Since INPUT is the 
default for the firet parameter and 1 is the 
default for the third parameter, this statement 
could be written as follows: 

COPYBRCMYHLE) 

The following is an order-ind^endent control statement. 

PURGE{ALPHA,FRED,TEST) 

This removes three user-created permanent files 
from the system. 

The f oUowir^ is an order-independent control statement. 

C0B0L5(I=TAPE1,B,L=TEMP) 

This initiates the compilation of source code 
read from a file TAPEl. The binary output from 
compilaticm is written on the system file BIN (B), 
and the source listing and diagnostics are written 
on the user-^)ecified file TEMP. 



CONTROL STATEMENT RECORD 

The first record of every job must be composed ex- 
clusively of all the CMitrol statements for the job. This is 
called the control statement record. It is this record 
which controls the details of job processing. 



The following examples are valid j<* statements. 

MYJOB. 
A. 

JONES. 
JOB2345. 



USER CONTROL STATEMENT 

A USER statement must follow the job statement if the 
installation requires validation. The USER statement 
establishes: 

• That the programmer submitting this job is a 
legal system user 

• What system resources the programmer may use 
and to what extent he may use them (appendix C) 

• The location of his permanent files (section 5) 



For all batch jobs, the USER statement must immediately 
follow the job statement. 

Format of the order-dependent USER statement is as 
follows: 

USER{usemum,passwor,family) 

usemum User number given the prc^ammer 

by the installation if validation is 
required. 

passwor Optional password which the user 

gives himself or is assigned (ap- 
pendix C). 
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family Identifies a family name. It is 

included only if the installation is 
using family names to group per- 
manent file devices. If the instal- 
lation is using family names and 
this parameter is not specified, the 
user is assigned to the default 
family. 

Example: 

USER(EFD2501,APRIL) 

The installation has g^ven this user the user number 
EFD2501 and has assigned him the password APRIL. 
Family names are either not in lee or if they are, this user 
will be assigned to the default family. 



CHARGE CONTROL STATEMENT 

If an installation is charging individual users for system 
resources used, it will give them charge number/project 
number combinations which must be included with their 
jobs. In such a case, a user must add a CHARGE 
statement immediately after his USER statement to 
access the system. Format of the order-dependent 
CHARGE statement is as follows: 

CHARGE(chargenum,projectnum) 

chargenum A 1- to lO-character alphanumeric 
charge number the installation 
gives the user 

projectnum A 1- to 20-character alphanumeric 
project number the installation 
may or may not give the user 

Example: 

CHARGE(510,299N9) 

The installation has given this user the charge number 
510, and the user is charging this job to the project 
designated 299N9. 

CONTROL STATEMENT RECORD COMMENTS 



A programmer can insert descriptive comments in a 
control statement record in the following manner. These 



comments will appear in the dayfile (appendix B) at the 
end of the printout from job processing. 

• Place the comment after the terminator of most 
control statements 

• Place the comment after the terminator of a 
COMMENT statement 

• Place the comment after a leading * 



Formats of a comment on a control statement are as 
follows: 

name(parameters)comment 

name.comment 

Format of a comment on a COMMENT statement is as 
follows: 

COMMENT.comment 

name Name of the control statement 

parameters Parameter list that goes with the 
control statement 

comment Character string that can begin in 
any column after the terminator 
but cannot go beyond column 30 

Format of a comment after an * is as follows: 

•comment 

The * can be in any column, but it must be the first 
nonblank character. The comment is a character string 
that can begin in any column after the * but cannot go 
beyond column 80. 

The dayfile format is 40 columns wide (appendix B). 
Comments which go beyond column 40 in the control 
statement record will appear as two lines in the dayfile. 
If a comment begins after column 40 on a control 
statement, it appears in the dayfile as two lines (a blank 
line followed by a line containing aU the characters 
following column 40). 

A job demonstrating comments is shown in figure 3-2. 
The dayfile printed when this job is processed is shown in 
figure 3-3. 
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EFD. 

0SER(EFD25,) 
CHARGE (59, Nil) 

»xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

COMMENT.THIS COMMENT IS TOO LONG TO BE COMPLETED BY COLUMN 80 AND SO AN ASTERISK 

•MUST BE USED TO BEGIN THE NEXT LINE. 

LIMITS. THIS COM^E NT FOLLOWS THE TERMINATOR OF A CONTROL STATEMENT.. 

• THIS COMMENT BEGINS IN COLUMN it 1 

COMMENT. THIS COMMENT IS CONTINUED TO AN ADDITIONAL 2 LINES. THE FINAL LINE 

» DOES NOT FOLLOW AN ASTERISK, A COMffiNT STATEMENT, OR A CONTBOL STATEMENT AND 

THEREFORE IT SHOULD PRODUCE AN ERROR MESSAGE AND JOB TERMINATION. 

•xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
•xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

6/7/8/9 



Figure 3-2. Comment Demonstration 



15.38.it2.EFD 

15.38.»I2.DSER(EFD25,) 

15.38.i(2.CHARGE(59,Nt) 

1 5 . 38 . 42 . "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

1 5 . 38 . 42 .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

15. 38. 42. COMMENT. THIS COMMEST IS TOO LONG TO BE C 

15.38.42.0HPLETED BY COLUMN 80 AND SO AN ASTERISK 

15.38.42.»MOST BE USED TO BEGIN THE NEXT' LINE. 

15. 38. 43. LIMITS. THIS COMMENT FOLLOWS THE TERHINA 

15. 38. 4 3. TOR OF A CONTROL STATEMENT. 

15. 38. 43. • 

15. 38. 43. THIS COMMENT BEGINS IN COLOMN 41 

15. 38. 43. COMMENT. THIS COHfENT IS CONTINUED TO 

15.38.43. AN ADDITIONAL 2 LINES. THE FINAL LINE 

15.38.43.* DOES NOT FOLLOW AN ASTERISK, A COM(EN 

15. 38. 43. T STATEMENT, OR A CONTROL STATEMENT AND 

15. 38. 43. THEREFORE IT SHOULD PRODUCE AN ERROR MES 

15. 38. 4 3. SAGE AND JOB TERMINATION. 

15.38.43. FORMAT ERROR ON CONTROL CARD. 



Figure 3-3. Printed Dayfile After Processing 



PROGRAMS 

A user can include programs in his job as separate records 
after the control statement recOTd. If these programs 
require data input, that too can be added as separate 
records. The user initiates compilation of these programs 
by inserting language E«WJessor call statement in the 
control statement record. Placement of these language 
statements matches the appearance of the program 
records in the job. The field length necessary for 
compilation is set by the system. 

This guide outlines the language statements for BASIC, 
FORTRAN, COBOL 4, and COBOL 5. The fwmats of 
these lai^age statements are as follows: 



3ASC(parameters) 
FTN(parameters) 
COBOL(parameters) 
C0B0L5(parameters) 



The common parameters for these formats are outlined in 
table 3-1. Parameters with default values (designated as 
omitted) are adequate for ordinary use. The full set of 
defaults for a particular language statement is in effect 
when the name and a terminator are used as follows: 

BASIC. 

FTN. 

COBOL. ^ 

C0B0L5. 



For BASIC, the default is automatic execution after 
compilation. For FTN and COBOL, the default is no 
pre^am execution after compilation. If the user intends 
to execute these programs, he must add a statement 
containii^ the name of the file to which the object code 
was written. If the file LGO is used by default, the 
format is as follows: 

LGO. 

This rewinds the compiled (binary) file, loads it into 
memory, and executes it. A compiled FORTRAN program 
will also execute if a GO has been included in the 
parameter list of the language statement (refer to table 
3-1). 

As an alternative, the user can put the compiled program 
on a file he names with the following parameter. 

B=lfn 
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To execute the compiled program Ifn, he follows it with 
the following statement, 

Ifn. 

A REWIND statement is unnecessary, since binary files 
are automatically rewound. 

Refer to the NOS Reference Manual, Volume 1 for a 
complete list of parameters and defaults for each of these 
language statements. 

Example 1: 

f 

The following job compiles and executes a FORTRAN and 
a BASIC program. 

JOBl. 

USER statement 

CHARGE statement 

FTN. 

LGO. 

BASIC. 

end-of -record 



FORTRAN 
cwogram 



end-of-record 



BASIC 
prc^am 



end-of-record 



data for 
the BASIC 
program 



The FTN statement initiates compilation of the next 
record in the job, the FORTRAN program. The LGO 
rewinds, loads, and executes the compiled program. The 
BASIC statement initiates compilation and execution of 
the next record in the job, the BASIC source program. 
Execution of the BASIC program calls for data ii^ut, 
which comes from the next (and last) record in the job. 

Example 2: 

The following job compiles a COBOL prc^am, puts the 
object code on a user file, and then executes that file. 

J0B2. 

USER statement 
CHARGE statement 
C0B0L(B=TEMP) 
TEMP, 
end-of-record 



COBOL 
program 



end-of-record 



data for 
the 003*^' 
program 



end-of -information 



end-of -information 



The COBOL statement initiates compilation of the next 
record in the job, a COBOL program. The object code is 
put on a user-designated file which he calls TEMP. To 
execute this object program, the user enters the file name 
as a control statement. The COBOL program requires 
data input, which comes from the next and last record in 
the job. 
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TABLE 3-1. COMMON PARAMETERS FOR LANGUAGE PROCESSOR CALL STATEMENTS 



Parameter 


BASIC 


COBOL 


C0B0L5 


FTN 


I 


Input on COMPILE t 


Input on INPUT 


Input on COMPILE t 


Input on COMPILEt 


I=lfn 


Input on If n 


I omitted 


Input on INPUT 


B 


Object code on BIN 


Object code on LGO 


Object code on BIN 


Object code <hi LGO 


B=lfn 


Object code on If n 


B omitted 


Compile-to-m em ory 
(no object code) 


Object code on LGO 


L 


Output on OUTPUT 


Output <Mi LIST 


Output on OUTPUT 


L=lfn 


Output on If n 


L omitted 


Batch: output on OUTPUT 
Time faring: no output 


Output on OUTPUT 


GO 


Object code loaded and 
executed 


N/A 


Object code loaded 
and executed 


GO omitted 


Compile-to-memory 


N/A 


Object code not loaded 
and executed 


tNot covered i 


n this guide. 
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LOCAL FILES 



This section explains the creation and characteristics of 
local files. It also describes the copy and file positioning 
control statements which are used with files local to a 
job. The following control statements are included in this 
section. 



COPYBR 


VERIFY 


COPYBF 


SKIPR 


COPYEI 


SKIPF 


COPY 


SKIPEI 


COPYCR 


BKSP 


COPYCF 


SKIPFB 


COPYSBF 


REWIND 



All copy operations begin copying from file Ifnl at its 
current position and begin copying to the current portion 
of lfn2 (an exception is the COPYEI statement). If lfn2 
does not exist, it is created by the system. If lfnl=lfn2, 
no copy taices place, and n records or files are ^E^>ed. 
After the copy operation, subsequent accesses of either 
file may begin where the copying stopped, at the BOX, or 
where the user has positioned the file. This depends upcm 
the parameters included with the copy statement or 
intervening file poationing statements (refer to Binary 
Coded Statements). 



BINARY COPY STATEMENTS 

Binary copy statements copy on a bit-by-bit basis and 
produce a duplicate of binary arid, in most cases, coded 
data. 



Unless he explicitly requests otherwise, the files a user's 
job creates are intended for the temporary use of the job. 
When job processing terminates, these temporary files are 
released. Such files are local files. Local files are 
distinguished from permanent files (section 5) which 
remain a part of the system when job processing ter- 
minates. 

A job can create local files in the following ways. 

• Using the name of the file for the first time in a 
copy statement (refer to Copy Statements) 

• Through fs-ogram execution 

• Malcii^ a copy of an existing p^manent file 
(refer to section 5) 



In the parameter lists of the control statement descrip- 
tions, a local file is identified by Ifn (local file name). 

The programmer, in his manipulations of files, may use 
the copy and file positioning control statements (refer to 
Copy Statements and File Positioning Statements). 



COPY STATEMENTS 



The following statements are the principal binary copy 
statements. 

C0PYBR(lfnj,lfn2,n) 

This cc^ies n records from Ifnj to lfn2. If the 
EOI on If ni is encountered befwe n records are 
copied, an EOF is added to lfn2. and the 
operation terminates. 

C0PYBF(lfnj,lfn2,n) 

This copies n files from Ifnj to lfn2. If more 
than one file is copied, the result is a multifile 
file. If the EOI on Ifnj is encountered before n 
files are copied, an EOF is added to If n2, and the 
operation terminates. 

C0PyEI(lfnj,lfn2,x) 

This copies file Ifn^ to file lfn2 until an EOI is 
eneoimtered on Ifni. If a third parameter (x) is 
present, both files are rewound before the copy 
and then, after the copy is completed, both files 
are rewound, verified, and rewound. This x 
parameter can be any 1- to 7-charaeter alpha- 
numeric name. The va-ifieation is a bit-by-bit 
comparison of the copy with the original. Errors, 
if found, are identified in the job output. 



Copy control statements make copies of files and records. 
The following parameters apply to all copy statements. 

Ifn, Source file of the copy (deration; default is 
^ INPUT. 

Ifn, File which will be the copy; default is 
OUTPUT. 



The followii^ copy statements in a job create three new 
files from two old files (figure 4-1). 

C0PYBF(0RIG1,NEW1) 
COPyBR(ORIG2,NEW2) 
C0PYBR(0R1G2,NEW3) 



Number of records or files to copy; default 
is 1. 
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0RIG1 



BOI 



BOI 



fim 



EOR 



EOR 
EOF 



C0I»YBF(0RIG1,NEW1) 



fint I 



EOR 



EOR 
EOF 



NEW1 



0RIG2 



BOI 



fint 



COPYBR(ORIG2^EW2) 



EOR 



EOR 
EOF 



KM 

I 

^ fiat 

EOR 



NEW2 



COPYBR(ORIG2^EW3) 



I B 



Xl ' } NEW3 
EOR I 



Figure 4-1. File Creation with Copy Statements 



CODED COPY STATEMENTS 

Coded copy statements copy on a eharacterHjy-charaeter 
basis. They treat the characters as constituting line 
images of up to 150 characters per line. Accordingly, the 
coded copy statements only duplicate information that is 
in coded lines (program output, text files, and so on). 

Primarily, a coded copy is employed to reformat a coded 
file. The following statements are coded copy state- 
ments. 

C0PYCR(lfnj,lfn2,n,fehar,lchar) 

This copies n coded records from Ifnj to 
Ifttj. If fchar and/or Ichar are present, they 
specify the first and last character of each 
line where copying begins and ends. Hus 
vertically truncated version of the original 
is left-justified in the copy. If fchar and 



Ichar are both omitted, no reformatting 
talces place. If the EOI or EOF is en- 
countered before n records are copied, an 
EOF is added to lfn2 and the copy operation 
terminates. 

COPYCF(lfni,lfn2,n,fohar,lchap) 

This copies n coded files from Ifnj to Ifnj. 
If n is greater than 1, these files are 
raultifiles. If fchar and/or Ichar are present, 
they specify the first and last characters of 
each line where copying begins and ends. 
This vertically truncated version of the 
original is left-justified in the copy. If fchar 
and Ichar are both omitted, no reformatting 
takes place. If the EOI is encountered 
before n files are copied, an EOF is added to 
If n2, and the copy operation terminates. 



*-2 
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COPYSBF(lfn,,lfn„.n) 



Tliis copies n files from If nj to lfn2, shifting 
each line one character to the right and 
addii^ a leading space. (A space is the 
E^inter carriage ecmtrol character for single 
spacing.) 

■nie character 1 is inserted at the beginning 
of each record as the files are copied. (A 1 
is the EH-inter carriage control character for 
starting a new page.) 

If an EOT is eneounta-ed befcffe n files are 
ct^ied, an EOF is added to Ifnj, and the 
operation terminates. 

TTiis copy statement is fM-imarily used to 
format the OUTPUT file for printii«. It fe 
possible to copy INPUT direcUy to OUTPUT. 
Using defaults, the control statement would 
be as follows: 

COPYSBF. 



The following list is a s^ment from an employee file 
called EMPLOYS. 



1445 


JONES. E. T. 


J22 


S6.25 


GS7 


1446 


KING, L. A. 


K921 


49.88 


GS7 


1447 


LANG, R. B. 


L404 


43.35 


GS7 


1448 


LONG, T. M. 


Lll 


38.97 


GSll 



This segment gives the sequence number, name, employee 
number, deductions, and rating for individual employees. 
To create a second file EMPL0Y4 with only the name and 
employee number, use the following statement. 

COPY CF(EMPL0Y3,EMPL0Y 4,1,7,30) 

This statement extracts the characters from columns 7 
through 30 and left-justifies them in the new file 
EMPLOY4. "nns file is as follows: 



JONES, E. T. 
KING, L. A. 
LANG. R. B. 
LONG, T. M. 



J22 
K921 
L404 
Lll 



ViRIFY STATEMENT 

The VERIFY statement makes a bit-by-bit comparison of 
two files to detect any variance between the contents of 
these files. This is a convenient way to check for errors 
in a copy op^ation. The basic format of this statement is 
as follows: 



VERIFYdfn, ,lf nB.p, .p»,...p_) 

Ifnj and Hn^ Two files being compared. 

p. Defines the comparison with 

the fallowing values. 

p. Description 

N=0 Verify terminates em 
the first empty file 
encountered on either 
file. 

N=x Verify x files; default 
is 1. 

N Verify terminates 

when EOI is encoun- 
tered on either file. 

R Rewind both files be- 

fore and aft« the 
verify. 

A Abort if error occurs. 



(Refer to the NOS Reference 
Manual, Volume 1 for the fuD 
range of p. values.) 

As an example, the followir^ job demonstrates the 
<^>eration of the VERIFY statement. Two input files with 
slight differences are copied into the system. The 
VMIFY statement is used to detect these differences. 

DEMO. 

USER Statement 

CHARGE Statement 

C0PYBR(,FILE1) 

C0PYBR(.FILE2) 

VERIFY(FILE1,FILE2.R) 

7/8/9 

$608.20 

$012.33 

$111.49 

7/8/9 

$608.20 

$012.34 

$101.49 

6/7/8/9 



The output from the vaification is shown in figure 4-2. 
The first wcrd was a match; the next two words were not 
and were listed in octal display code with the logical 
difference of each pair to pinpoint the location in the 
word where the difference was found. The first error is 
dis^ammed to show how this is read. 
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VESirr ERROR LIST. FILE 1 

..-- nt^ia^ unTA vn\fn ri.L6 1 



RECORD TTfPE TEXT/$608.20 



5333 3135 5736 3655 OOOO-i 
533* 3t3t 5737 4155 0000 



$ 12 



■ndof 
Sbtoik Him 




77/07/28. 
DATA FROM FILE2 

TEXr/$608.20 

•5333 3«35 5736 3755 0000 
533'* 333* 5737 tlSS 0000 



15.55.13. PAGE 1 

LOGICAL DIFFERENCE 



0000 0000 0000 0100 0000 
0000 0700 0000 0000 0000 



$ 12 



4 btoik 



fndof 




S333 3435 S736 3666 0000-4 — I t-^5333 3435 57M 3756 0000 



5333 3«6 5736 3665 0000 



logicii dmmnc*- 



-» 0000 0000 0000 0100 0000 



Figure 4-2. Output from Processing a VEEIFy Statement 



FILE POSITIONING STATEMENTS 

File positionii^ control statements reposition the current 
position of a file for selective reading, writing, and 
copying. Only the principal parameters are ecplained; the 
full set of parameters for each statement is given in the 
NCS Reference Manual, Volume 1. 



BACKGROUND 

The current position of a file is the location in the file 
where the next operation that accesses the file will begin 
to read or write data. This location can be at the BOI, 
after an EOR, after an EOF. or at the EOL Reading 
records from a file can leave the current position at the 
end of the last record read, writing a file with a program 
can leave the current position at the end of the last 
record written, and copying statements can leave the 
current position of both the original and the copy after 
the last record or file copied. 



FORWARD POSITIONING STATEMENTS 

The following statements move the current position of a 
file forward toward the EOI. 

SKIPR{]fn.n) 

This moves the current position of the 
named file (Ifn) fcrward the designated 
number of records (n). EOF marks are 
separate records and are included in the 
record count. If the EO! is encountered 
before n fUes are passed, the current 
position remains at the EOI. 



SKIPF(lfn.n) 



This moves the current position of the 
named multifUe file (IfiO forward the 
de^gnated numbCT of files (n). if the EOI is 
encountered before n files are passed, the 
current position remains at the EOL 

SKIPEKlfn) 

This moves the current position of the 
named file or multifUe file (Ifn) to EOI. On 
magnetic tapes, which have no EOI, the 
operation stops at the EOF indicator. 

BACKWARD POSITIONING STATEMENTS 



The following statements move the cuirent position of a 
file backwards toward the BOI. 



BKSP(lfn.n) 



This moves the current position of the 
named file (Ifn) backwards the designated 
number of records (n). EOF indicators are 
separate records and are included in the 
record count. If BOI is encountered before n 
records are passed, the current position 
remains at the BOI. 



SKIPFB(lfn,n) 



This moves the current position of the 
named multifile file (Ifn) backwards the 
designated number of files (n). If BOI is 
encountered before n files are passed, the 
current position remains at the BOL 
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REWINDflf n. .If n ) 

1- %■ 

This moves the current positions for files 
lfnj^,lfn2,." back to the BOI. 

The following job is made i^ of file positioning statements 
and one-line records organized into files. This job 
demonstrates the operation of the positioning statements. 

job statement 

USEE statement 

CHARGE statement 

COPYEK.DEMO) 

REWINIXDEMO) 

SKIPR(DEM0,4) 

BKSP(DEM0,3) 

SK1PF(DEM0,2) 

BKSP(DEMO,10) 

SKIPEKDEMO) 

SKIPFB(DEM0,3) 

REWINIXDEMO) 

7/8/9 

FILE 1 * RECORD 1 

7/8/9 

FILE 1 * RECORD 2 

7/8/9 

FILE 1 * RECORD 3 

7/8/9 

6/7/9 

FILE 2 * RECORD 1 

7/8/9 

6/7/9 

FILE 3 *RECORD 1 

7/8/9 

HLE 3 * RECORD 2 

7/8/9 

6/7/9 

FILE 4 • RECORD 1 

7/8/9 

FILE 4 * RECORD 2 

7/8/9 

6/7/9 

6/7/8/9 



Figure 4-3 shows the structure of this multifile file in 
memwy and how the position is moved by the operation of 
each control statement. "Rie crossmarks on the broken 
lines show the terminators that were counted in the 
operation. If this multifile file had had only one EOF 
before the EOI, operation 7 would have moved the position 
to FILE 2 * RECORD 1. 



+ 
I 
I 

T 

I 
J. 

I 

T 



FILE 1 • RECORD 1 •<-®- 
-END OF RECORD- 
FILE 1 * RECORD 2 
-END OF RECORD- 
FILE 1 * RECORD 3 
-END OF RECORD- 
-END OF FILE- 
FILE 2 * RECORD 1 
-END OF RECOBD- 
-END OF FILE- 
FILE 3 * RECORD 1 
-END OF RECORD- 
FILE 3 * RECORD 2 
-END OF RECORO- 
-END OF FILE- 
FILE 4 * RECORD 1 
-END OF RECORD- 
FILE 4 RECORD 2 
-END OF RECORD- 
-END OF FILE- 
-END OF FILE- 
-END OF INFORMATION- 



NOTES: 

REWINO(DEMQ) 
® SKIPRIDEM0,4) 
@ BKSP(DEMO,3) 
® SKIPF(DEM0.2) 
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© BKSP(DEMO,10) 

© SKIPEKDEMO) 

® SKIPFB(DEM0,3) 

<S\ REWINDlDEMO) 



Figure 4-3. Operation of File Positioning 
Statements on a Multifile File 
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PERMANENT FiLiS 



This section explains how a user can create files within 
the ^stem and preserve them beyond job processing. The 
following control statements are described in this secticm. 



SAVE 


ATTACH 


GET 


CHANGE 


REPLACE 


PURGE 


APPEND 


PERMIT 


DEHNE 


CATUST 



Only the principal parameters are expletined; the complete 
set of parameters for each control statement is given in 
the NOS Reference Manual, Volume 1. 

A user can create, access, and modify mass storage files 
that remain within the system until he or the installation 
specifically removes them. These files are called per- 
manent files. 



Permanent files are either indirect or direct access 
according to the mcmner in which they are accessed. An 
indirect access permanent file is accessed by making a 
local copy and having control statements operate on that 
«^y rather than the OTiginal. This copy will be released 
after job processing unless the user specifically saves it as 
an added permanent file or uses it to r^lace the original 
version. A direct access file is accessed in place; that is, 
control statements interact with the permanent file. No 
copy is made. 

Direct access permanent files offer a variety of multiple 
access (simultaneous access of a single file by two or 
mcH-e users) capabilities not available with indirect access 
files (refer to section 8 of the NOS Reference Manual, 
Volume 1). Also, direct access files have greater I/O 
efficiency, because no intermediate copy is used. For the 
time-sharing user, an advantage of the direct access file 
is that all modifications and additions are made directly 
on the permanent file and ^ould the terminal become 
disconnected or the system go down, all previous work is 
not lost. However, care must be taken in altering a direct 
access file since all alterations (correct and erroneoie) 
are made directly to the permanent file, not a copy. 

Indirect access files require smaller allocations of mass 
storage space than direct access files. "niiB, permanent 
files that are smaller in size are typically made indirect 
access files. The character content of this section on 
permanent files is a good measure of the upper limit for 
an indirect access permanent file. 



INDIRECT ACCESS PERMANENT FILES 



HOW TO CREATE AN INDIRECT ACCESS 
PERMANENT FILE 

The data that is to be made an indirect access permanent 
file must first exist ^ a local file. This local file may be 
created in any manner by job processing. The system 
copies the local file to the permanent file space on mass 
storage when the user includes the following control 
statement in a control statement record. 



SAVBOfn) 
Ifn 



Name of the local file 



The permanent file copy will have the same name. If the 
user Wants the permanent file to have a different name, 
he uses the following form. 



SAVE(lfn=pfn) 
pfn 



Name the user gives the indirect access 
permanent file. This name must be 
used for future access of this per- 
manent file. 



The SAVE statement copies the entire file; that is, the 
permanent file will contain the entire local file whatever 
the current position of Ifn when the SAVE statement is 
processed. After SAVE is processed, the local file is 
rewound. 

In the following example, an input record is made a local 
file with the name A. This local file is made an indirect 
access permanent file with the same name. 

COPYBR(,A) 
SAVE(A) 

A job contains the following control statements. 

BAS1C(B=ZETA) 
SAVE^ZETA) 

The BASIC statement compiles a BASIC source program, 
which is a record in the same job. The binary object code 
is put on a local file with the name ZETA. The SAVE 
statement makes this local file an indirect access per- 
manent file with the same name. 



60436300 A 



5-1 



HOW TO ACCESS AN INDIRECT ACCESS 
PERMANENT FILE 

A local copy of an indirect access permanent file can be 
obtained by the creator of the permanent file if he 
includes the following control statement in the control 
statement record of a job he submits. 

GETXpfn) 

If the user wants the local copy to have a different name, 
he enters: 

GET(]fn=pfn) 

Ifn Temporary name the user has chosen 

for the local copy to be made from pfn 



APPEND(pfn,lfnj.lfn2....) 



copy is always at the BOI after GET is 
If a local file named Ifn existed before the 



The local 

processed. 

GET request, it is lost when GET is processed 

Example 1: 



To obtain a local copy of the indirect access permanent 
file A created in a previous example, the user enters the 
following control statement. 

GET(A) 

If he wants the local copy to have the name INFILE, he 
enters: 

GET(INnLE=A) 

Example 2: 

To execute the BASIC program compiled and saved in a 
previous example, the user includes the following control 
statements in a job. 

GETtZETA) 
ZETA. 



HOW TO ADD INFORMATION TO AN INDIRECT 
ACCESS PERMANENT FILE 



The user can make additions to one of his indirect access 
permanent files if the additions are first made local files. 
He adds these local files to the permanent file with the 
following APPEND control statement. 



pfn Name of the indirect access per- 

manent file to receive the ad- 
ditions 

(lfnj^,lfn2,...> Local files that constitute the ad- 
ditions 



For example, a user keeps a weekly journal of 
transactions. This is an indirect access permanent file 
called JOURNAL. Approximately every day he adds new 
transactions to this file. To add the transactions for 
Thursday and Friday, which have been made into two local 
files called THUR and FRI, he enters the following control 
statement. 



APPEND(JOURNAL,THUR,FRI) 



HOW TO MODIFY AN INDIRECT ACCESS 
PERMANENT FILE 

If the user wants to modify one of his indirect access 
permanent files, he can do one of the following. 

• Get a local copy, alter the local copy with 
positioning and copy statements or with a pro- 
gram, and then replace the existing permanent 
file with this new vision 

• Produce a new local file and, without getting a 
copy of the existing permanent file, replace the 
permanent file with the new local copy 



In either case, the REPLACE control statement replaces 
the existing pfn with the new Ifn. If pfn and Ifn have the 
same name, the format of the statement is as follows: 

REPLACE(pfn) 

If the local copy has a different name, the format is as 
follows: 

REPLACE(lfn=pfn) 

For example, a firm maintains a file of 18 part listings. 
Each listing is a single record in the file. The file is an 
indirect access permanent file called PARTLST. At a 
particular date, this file will be updated with one deletion 
and two additions. The updated file will have 19 part 
listing records; the job is as follows: 



S-J 



«a4363ae a 



job statement 

USER statement 

CHARGE statement 

GET(LOCALl=PARTLSD 

COPyBR(LOCAH,LOCAL2,5) 

COPYBR(,LOCAL2,l) 

COPYBR(LOCALl,LOCAL2,7) 

SKIPR(L0CAL1,1) 

COPYBR(LOCALliLOCAL2,3) 

C0PYBR(,L0CAL2,1) 

COPYBR(LOCALl,LOCAL2,2) 

REPLACE(L0CAL2=PARTLST) 

—end-of -record— 



First Addition 



— end-of-reeord— 



Second Addition 



— end-of-infOTmation 



Figure 5-1 outlines the job processing that creates the 
updated file. A local copy (LOCALl) of the indirect 
access permanent file PARTLST is made. By copying 
from this file and the INPUT reewds, a second local file 
(L0CAL2) is created. This file has one deletion and two 
additions. Finally, L0CAL2 replaces the existing per- 
manent file PARTLST. Future access of PARTLST will 
receive a copy of this updated version. 



COPY 
LOCALl OPERATIONS L0CAL2 



INPUT 



RECORDS 
1-5 


- 


S 
RECORDS 






RECORDS 
6-12 


"■"•-^-^^ 


1 RECORD 


-•— 


ADD1 


- 


7 
RECORDS 






RECORD 13 






REC»RJ» 
14-16 


- 


3 
RECORDS 




RECORDS 
17,18 


^~~" 


1 RECORD 


«•— 


ADD2 I 


2 
RECORDS 






EOl 


■^-^..^ 





EOt 



Figure 5-1. File Update 



DIRECT ACCESS PERMANENT FILES 

HOW TO CREATE A DIRECT ACCESS PERMANENT 
FILE 

A user can create a direct access permanent file by 
defining an area of mass storage for that purpose with the 
DEFINE control statement and then copying a local file or 
input information to that area. The basic format of the 
DEFINE control statement is as follows: 

DEFINE(pfn) 

pfn Name the direct access file wiU have 

In the following example, the first statement defines an 
area on mass storage for a direct access file with the 
name FILE24, and the second statement copies an input 
file to this area. 

DEnN]KFILE24) 
C0PYBF(.FILE24) 



The following example defines a direct access file with 
the name NEWFILE and obtains local copies of two 
indirect access permanent files (TESTl and TEST2). 
TEST! is positioned to the fourth record, and the fourth, 
fifth, and sixth records are copied to NEWFILE. TEST2 is 
positioned to the third record, and the third and fourth 
records are added to NEWFILE with a copy. NEWFILE is 
rewound and cc^ied to the printer for verification. 

DEFINKNEWFILE) 

GET(TEST1,TKT2) 

SKIPR(TEST1,3) 

C0PyBR(TESTl,NEWFILE,3) 

SKIPR(TEST2.2) 

C0PYBR(TEST2,NEWFILE,2> 

REWIND(NEWFILE) 

COPYSBF(NEWFILE.) 



HOW TO ACCESS A DIRECT ACCESS PERMANENT 
FILE 



A user can access a direct access permanent file he has 
created by including an ATTACH control statement in a 
job he submits for processing. Hie basic format of this 
statement is as follows: 
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ATTACH(pfn) 

pfn Name of the direct access permanent 

file being accessed 

After processing this statement, control statements that 
follow in the same job can interact directly with the 
contents of this file. 

If the user wants to access the direct access file with a 
different name during job processing, he employs the 
following format. 

ATTACH(lfn=pfn) 

Ifn Temporary substitute name 



HOW TO MODIFY A DIRECT ACCESS PERMANENT 
FILE 



The copy and file positioning control statements can be 
employed by a fg'Ogrammer to alter his direct access files. 
However, if the programmer is periodically updating large 
files, he diould investigate the capabilities offered by the 
system utility control statements (refer to section 14, 
NOS Keiefence Tvlanual, Volume 1). 

Whenever the user initiates alteratiwis of a direct access 
permanent file, he makes changes to the permanent file, 
not a temporary copy. As a jweeaution against inadvert- 
ent modification of a direct access file, the system 
requires the user to specify write mode on an ATTACH 
statement before he can alter the file attached. The 
format of an ATTACH statement that grants write 
privil^es is as follows: 

ATTACH(lfn=pfn/M=W) 

M=W Signifies mode equals write 



Example 2: 

The following control statements replace the fifth record 
of a direct access file. 

ATTACH(NEWFILE/M=W) 

SKIPR(NEWFILE,4) 

C0PYEI(NEWF1LE,TEMP) 

REWIND(NEWFILE,TEMP) 

SK1PR(NEWFILE,4) 

COPYBR(,NEWFILE) 

SKIPR(TEMP) 

C0PYE1(TEMP,NEWFILE) 



These statements attach the diriect access file NEWFILE 
in write mode, skip four records, and copy the remainder 
of the file to a temporary file called TEMP. A new input 
record is copied to NEWFILE as a fifth record. Tire first 
record in TEMP is skipped, and the remainder of TEMP is 
returned to NEWFILE. 



PURGING PERMANENT FILES 

The user can purge (remove from the system) one or more 
of his indirect and direct access permanent files by 
includii^ the PURGE control statement in a job. The 
basic format of this statement is as follows: 

PDRGE(filej,file2,...) 

filej,file2,... Names of the user's permanent 

files to be removed from the 
system. The removal is per- 
manent, and they can in no 
way be accessed in the future. 



ALTERNATE ACCESS OF PERMANENT FILES 



Example 1: 

The following job adds a new record to an existing direct 
access permanent file called LISTING. 

job statement 

USER statement 

CHARGE statement 

ATTACH(LISTING/M=W) 

SKIPEKLISTING) 

COPY(,USTING) 

7/8/9 



new 

record 



6/7/8/9 



A user can grant other users access permission to his 
permanent file by selecting an appropriate access cate- 
gory when he creates the file. He selects this category 
with an added parameter on the SAVE or DEFINE 
statement. This parameter is a keyword with the 
following form. 



CT=et 



et 



One of the following access cat^ories 
of a permanent file. 

P Private file. This limits 

access to the originator o{ 
the file unless he specifies 
individual alternate users 
with the PERMIT control 
statement (explained 

later). Private is the de- 
fault category for per- 
manent files. 
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Seinippivate file. "Hiis 
limits access to the origi- 
nator and otttec users who 
include the foQowiner pa- 
rainet^s on a GET of 
ATTACH control state- 
ment. 

• Name oi the Hie 

• Dser number of the 
(^iginatcv 

• Passwcvd specified by 
the orisinatOT for thb 
file (»iginatort5 op- 
tini) 



PWa gwtttg MTor 



passwor 



A 1- to 7-fllphanumeric character 
password 



If a user wants to create an indirect access permanent file 
that can be accessed by others, he uses the followit^ 
format of the SAVE statement. 

SAVE0fn^fn/PW=p8sswor,CT=ct,M=m) 

An altotutte user who wants a copy of this file includes 
the following format of the GET control statement in his 
Job. 

GET(lfn=pfn/PW=passwor,UN^=usernum) 

us«muin Dser number of the file's csiginatw 



PU 



The system keeps a de- 
tailed record of all alter- 
nate accesses to this file. 
This record is available 
with the CATUBT control 
statement (explained 

later). 

Public file. Access re- 
quirements are identical 
to the semiprivatie file; 
however, the ^stem 
keeps a record only of the 
total number of accesses. 



The keywcmis PW=, CT=, M=, and UN= appear in any order 
afta the slash. The slash is a required separator that 
must come after the file names if any keywonte are to be 
used. 

Example 1: 

A us^ with user number AB22 creates an indirect access 
permanent file called DATA8. He gives it the password 
ABC, makes it piAtlic. and grants read mode to alternate 
users. The format of the SAVE statement wlOi which he 
does this is as foQows: 

SAVB(DATA8/PW=ABC,CT=PU,M=R) 



In addition to establishuig an access category, to deter- 
mine who can acc^s the file, the or^inator can establi^ 
an access mode to determine how an alternate user can 
access the file. Mode is specified on the SAVE or DEFINE 
ccmtrol statement with the foUowing keyw(H*d parameter. 

M=m. . 

Tins guide consida^ only two values of m, R (read) and W 
(write). Eight modes are available and are explained in 
theNOS Reference Manual, Volume 1. 

If read is ^>ecified with M=R, alternate users can only 
read the file after accessing it. If write is specified with 
M=:W, alternate users can read and write after accessing 
the file. 

The (H-iginator of an indirect access permanent file 
automatically has read and write permission when he 
accesses that file. Fot a direct acc«s file, the default 
mode is read, and the user must specify M=W if he intends 
to write on it. 



If the originator of this file wants a copy, he uses the 
foUowing statement. 

GET(DATA8) 

If an alternate user wants a copy of ttiis file, he inserts 
the following statement in his job. 

GET(DATA8/UN=AB22,PW=ABC) 

If the originator of a permanent file has made it private 
by default or specifiration, he can grant altwnate access 
only to users he specifies on a subsequent PERMIT 
statement. Fwmat d this statement &s as follows: 

PERMIT(pfn,usemum^=m.,usemum2=m2...) 

User numbers of those who are 
being granted access permission to 
the private file with the name pfn 



uswnum. 



m, 



Permission modes R (read) and W 
(write) 



The originator of a permanent file can give that file 
greater security by associating a password with it. This 
passw<»4 has no relation to the password included on the 
USER control statement, which gives access to the 
system. The file pa^word is specified on a SAVE or 
DEFINE statement with the follonring keyword paramet^. 



Example 2: 

A user with user number AB22 includes the following 
control statements in a j^. 

SAVE(LIST28) 
PERMmiJST28.SM182=R) 
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SAVE creates an indirect access permanent file LIST28 
with jwivate category and no password. Tne permit grants 
read access to the alternate user with user number SMi82. 

To obtain a copy of LIST28, the alternate user includes 
the following control statement in his job. 

GET(L1ST28/UN=AB22) 

If the user wants to create a direct access permanent file 
that can be accessed by others, he uses the following 
format of the DEFINE control statement. 

DEnNE(lfn=pfn/PW:^>asswor,CT=ct,M=m) 

An alternate user who wants to access this file includes 
the following format of the ATTACH statement in his job. 

ATTACH(lfn=pfn/PW=passwor,ON=usemum,M=m) 

Ifn Optional substitute name for the per- 

manent file name pfn 

UN User number of the originator of the 

fUe 



If the originator of an indirect or direct access permanent 
file wants to change the access parameters for that file, 
he uses the CHANGE control statement. Format of this 
statement is as follows: 

CH ANGE(nf n=of n/P W^»asswor,CT=ot, M=m) 



nfn 



Optional new file name that will re- 
place the old file name ofn. The 
keyword parameters PW=, CT=, and M= 
are included only if they are to be 
changed. If the password is to be 
cancelled, the user sets PW=0 (zero). 



Example 4: 



A direct access permanent file called ZZ3 has the 
password PASS2. Read permission has been granted to 
alternate users. Tlie originator of this file changes the 
password to PASS3 and the access mode from read to 
write with the following control statement. 

CHANGE(ZZ3/PW=PASS3.M=W) 



iiie uciBUii aiOue IS ivi=n,. u uie aiiernaie user nas oeen 
panted write permission for this file and wants to 
exercise that permission, he must include M=W, as the 
originator must do. 

Example 3: 

A user with user number AA29A creates a direct access 
file called XX7X. He assigns the password ENTER, 
estat>lishes the category as semiprivate, and specifies 
write permission for alternate users with the following 
statement. 

DEFINE(XX7X/PW=ENTER.CT=S,M=W) 

If the originator of this file wants to access it, he uses the 
following control statement. 

ATTACH(XX7X) 

If the originator wants to write on it, he uses the 
following statement. 

ATTACH(XX7X/M=W) 

If an alternate user wants to access this file for reading, 
he includes the following control statement in his job. 

ATTACH{XX7X/PW=ENTER,ON=AA29A) 

If an alternate user wants to access this file for writing, 
he includes the following control statement in his job. 

ATTACH(XX7X/PW=ENTER,UN=AA29A,M=W) 



HOW TO OBTAIN A LISTING OF 
PERMANENT FILES 

The system maintains a separate catalog of each user's 
permanent files. A user's catalog contains the names, 
characteristics, and histories of his current permanent 
files. Catalogs are continually updated as permanent files 
are created, accessed, modified, or purged. A user can 
obtain a listing of permanent files (his and others he can 
access) by including the CATLIST control statement in 
one of his jobs. The listing is put in the OUTPUT file for 
that job. 

A user can obtain a listing of the names of his permanent 
files with the following version of the control statement. 

CATUST. 

A user can obtain a listing of the names of permanent 
files of an alternate user that he can access with the 
following version of the control statement. 

CATLIST(UN=usernum) 

usernum User number of the alternate user 

If the user wants the names, characteristics, and histories 
of all his permanent files, he uses the following control 
statement. 

CATIJST(LO=F) 

If the user wants the names, characteristics, and histories 
of all the permanent files in an alternate user's catalog 
that he can access, he uses the following control state- 
ment. 
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CAntOG OF useroua 



rr/ma/dd. hh.nn.ss. 



FILE nam; access file-type leugth dh creatiok last access last mod 

PASSWORD MD/CKT ISDEX PEHM SDESIS DATE/TIHE DATE/nHE DATE/nME 



Figwe 5-2. CATLIST Parameter LO=F Headir^ 



CATLIST(LO=F,DN=usemiiin) 

usemum User number of the alternate user 

The headings minted out for a full listing (LO=F) are given 
in figure 3-2. The terms in these headings have the 
following significance. 

yy/mm/dd Year, m<mth, and day of the listing. 

hh.mm.ss Listing time in hours, minutes, and 

seconds. 

FILE NAME Name of each file listed aft«- a 

sequence number. 

PASSWORD File E>assword if one is given. This 

term is missing from listings of 
alternate catalogs. 

ACCKS Tliis entry will be IND if the file is 

MD/ indirect access or DIR if the file is 

direct access. 

/CNT Count of the number of times the 

file has been accessed (originator 
and alternate users). 

FILE-TYPE Access cat^ory (PRIVATE, SEMI- 

PRIVATE, or PUBUC). 

INDEX Reserved for system use. 

PERM. Permission mode, fo tite exam^es 

in this guide, this can be READ or 
WRITE. 



LENGTH File ler^^ given in decimal num- 

ber of characters. The minimum 
that will be shown is 640 charac- 
ters however smaU the file. 

SUBSYS Files created in a time-sharing 

session with a subsystem associated 
with them (FTNTS, BASIC, 
BATCH, or EXECUTE). If this 
field is blank, no subsystem is 
associated with the file. 

DN Gives a device number for direct 

access files. An asterisk in this 
column indicates the file is on the 
user's master device. This device 
holds the user's catalog and all his 
indirect access permanent Hies. 

CREATION Two-line entry giving the date and 
DATE/TIME time of file creatiou 

LAST ACCESS Two-line entry giving the date and 
DATE/TIME time of the last access of this file. 

LAST MOD Two-line entry giving the date and 
DATE/TIME time of the last modification of 

this flie. 

Refer to the NOS Reference Manual, Volume 1 for 
additional catalog listings. 
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CONTROL LANGUAGE 



A user inserts control language statements into the 
control statement record of a j<* to give the sequence of 
control statements a program-like structure; that is, 
ncH-mELl unconditional processing of control statements in 
series is modified so that tests, transfers, and loe^s are 
initiated within these statements as if they were lin^ in a 
program. This action outlines the foUowir^ control 
language statements. 

SET 

DBPLAY 

IF 

GOTO 

CALL 

Only the basic parameters needed by the applications 
programmer are included. The fun range of parameters is 
given in section 4 of the NOS Reference Manual, Volume 
1. 



FORMAT 

A control language statement consists of a descriptive 
name followed by symbolic names and/or an ex[xression. 
Separat<M-s and terminators are unique and must be used as 
shown in the individual formats. 



The q>ecial embolic names used in this expression ^>ecify 
the status to be determined. Evaluation of the escpression 
will give a value of 1 if it is true and a value of if it is 
false. The following are embolic names and their use. 



File Type: 




LO 


Local 


PB 


Print 


IN 


Input 


PH 


Punch 


PM 


Direct access permanent file 


File Location: 


AS 


File assigned to the user's job 


MS 


Mass storage 


MT 


7-track magnetic tape 


NT 


9-traek m^netic tape 



The FILE function is explained in subsequent descriptions 
and examples. 



SET STATEMENT 



EXPRESSIONS 

The expressions used with control language statements are 
similar to the exfH-essions used with highe-level lan- 
guages. These may contain constants, arithmetic op^a- 
t<»s, relational operators, boolean operators, functions, 
and symbolic names (refer to appemfix E for a listing of 
the operators). 



FILE FUNCTION 

The FILE function is used as a parameter in the SET, 
DISPLAY, and IF ccmtrol language statements to deter- 
mine the status of any file assigned to the job. Status 
includes file ^pe, locaticn, and accessibility. The format 
of the FILE function te as follows: 

FILE(lfn,express!on) 

Ifn Name of the file for which status is 

being det«-mined 

expression Legal expression; parentheses must 
be used 



SET control language statement sets a value in one of the 
software registers reserved for control language use. 
Format of the statement is as follows: 



SET(Ri=expression) 



expression 



Identifies one of three 18-bit soft- 
ware registers; can be 1, 2, w 3. 

Legal ex[v^sion; parentheses must 
be used. 



The boolean values TRUE or T and FALSE or F can be 
^>ecified as the expression. These values are stored as 1 
and 0, respectively. 

As an example, the following SET statement included in a 
control statement loop will increase Rl by one each time 
the loop is processed. 

SET(R1=B1+1) 

Additional uses of the SET statement are given in the 
examples for other control language statements. 
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DISPLAY STATEMENT 

The DISPLAY control l&ngusge statsmsnt svcsluates an 
expression and displays the result In the job's dayfile. 
Numerical values are displayed in decimal and octal. If 
the evaluation gives a true/false value, a 1 or will be 
displayed, respectively. Format of the DISPLAY state- 
ment is as follows: 



DISPLAY(expresslon) 



expression 



Legal expression; parentheses must 
be used. 



Example 1: 

An input copy operation is repeated in a control statement 
loop using: 

SET(R1=R1+1) 

A second copy operation is repeated with: 

SET(R2=R2+1) 

To obtain a printout of the total number of copies made, 
the user includes the fo1Iowin<r in the control statement 
record. 

SET(R3=R1+R2) 
DISPLAY(R3) 

If Rl is 8 and R2 is 3, the entry in the dayfile is as 
follows: 



DBPLAY(R3) 
11 



13B 



The iser can employ the angle statement 

DISPLAY(R3=R1+R2) 
and get the same entry in the dayflle. 



GOTO STATEMENT 

The GOTO control language statement initiates an uncon- 
ditional transfer of control statement processing to a 
named statement. Format of the statement is as follows. 



GOTO,stmt. 



stmt 



Identification of the statement in the 
control statement record to which Rec- 
essing will transfer; the comma and 
period are required. The statement 
identification may be any of the follow- 
ing. 

• Name of a control statement (GET, 
COPYBR, and so forth). 

• Name of a control language state- 
ment (SET, DISPLAY, and so 
forth). 

• Alphanumeric identifier placed at 
the beginning of the statement to 
which control is to be transferred. 
The statement identifier must be- 
gin with a decimal digit and may 
have up to six alphanumeric ciiar- 
acters following this digit. The 
identifier is separated from its 
statement by a comma. 



If two or more statements in the control statement record 
have the same name, control will pass to the first 
occurrence. 



Example 1: 

In the following loop from a control statement record, one 
GOTO repeats the loop when the exit condition is not met. 
The other GOTO causes an exit from the loop when the 
exit condition is met 



Example 2: 

The following statements make a local copy of a 
permanent file and test to see if it is on mass storage. 

GET(ALPHA) 

SET(R1=FILE(ALPHA.MS)) 

DISPLAY(Rl) 

if ALPHA is on mass storage, the following entry is made 
in the job's dayfile. 



2L00P.D1SPLAY(R1) 



SET(R1=R1+1) 

(exit condition)GOTO,COMMENT. 

G0T0,2L00P. 

COMMENT. END 



DISPLAY(Rl) 
1 



IB 



Example 2: 

Figure 6-1 shows a job demonstrating various possibilities 
of the GOTO statement; the resulting dayfile is shown in 
figure 6-2. 



If ALPHA is not on mass storage, the following entry is 
made in the job's dayHle. 



DBPLAY(Rl) 




OB 
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1^5 
I 
6 



^10 

11 
I 
12 



GOTOJOB. 

USER StMamant 

CHARGE Statnrant 

SET(R1-409e) 1 

1 
6OTO,100. 2 

COPYBRCLFNII 

GOTO,200. 

0ISPLAY(R2) 

C0PYBR{LFN1,LFN2) 

GOTO,REWIND. 

2XYZ,COPYSBF{LFN2,) 

GOTO,COMMENT. 

200,REWINO(LFN1) 

SET(R>100000B) 

GOTO,DISPLAY. 

REWINCMLFNZ) 

GOTO^YZ. 

108,H3ISPUAY(RH 

GOTO,COPYBR. 

OJMMENT. END OF DEMONSTRATION 

7/8/9 

TEST OF THE GOTO CONTROL LANGUAGE STATEMENT 

6/7/8/9 



3 

I 

4—' 



7 
I 
8 

9—' 



^15 
1 
16 



13 
14- 



—17 



Figure S-1. GOTO Job Demonstration 



17.07, 
17.07, 
17.07, 
17.07, 
17.07, 
17.07, 
17.07, 
17.07. 
17.07, 
17.07, 
17.07, 
17.07, 
17.07. 
17.07, 
17.07, 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07, 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 
17.07. 



19 

19 

19 

20 

20 

21. 

21. 

21. 

22. 

23. 

24. 

2^. 

24. 

24. 

24. 

24. 

25. 

25. 

25. 

25. 

27. 

29. 

29. 

29. 

29. 

30 

30 

30 

20 

30 

38, 



EFD. 

USER(EFD2501,) 
CHARGE ( 404, ACCTlt) 
SETCR 1=4096) 
GOTU.IOO. 
100,DISPLAY(R1) 

4096 10000B 

GOTO, COP YBR. 
C0PYBR(,LFN1) 

COPY COMPLETE. 
GOTO, 200. 
200,REWIND(LFN1) 
SET(R2=100000B) 
GOTT), DISPLAY. 
DISPLAY (R2) 

32768 100000B 

C0PYBR(LFN1,LFN2) 

COPY COMPLETE . 
GOTO, REWIND. 
REWIND(LFN2) 
G0TO,2XYZ. 
2XYZ,C0PYSBF(LFN2,) 

END OF INFORMATION ENCOUNTERED. 
GOTO, COMMENT. 



COMMENT. END OF DEMONSTRATION**** 

UEADi 0=0Q2KUNS. 

UEPF, 0.015KUNS. 

UEMS, 0.0540KaNS. 

OECP, 0.119SECS. 

AESR, 2.205UNTS. 
32, 0.320 KLNS. 



IF STATEMENT 

The IF control language statement is analogous to the 
conditional branch found in higher-level languages. It 
states a conffition which, if met, initiates processii^ of a 
statement on the same line; if the concfition is not met, 
the statement is ignwed and control passes to the next 
statement. Format of the IF statement is as follows: 

IF(expression)stmt. 

expression Legal expression 

stmt Control statement or control lan- 

guage statement 

The parentheses and period must be used as ^own. 

Example 1: 

The following example tests the file TERM to see if it is a 
local file. If it is, control passes to the statement 
identified with 200; if it is not, roister Rl is set to 0. 

IEffJLE(TERM,LO)) GO TO ,200. 
S E T (Rl = FAI^E) 



200,»TRUE 

Example 2: 

IF(R1=R2)DISPLAY(R1). 

If these roisters have the same value, that value will be 
displayed in the dayfile. 



CALL STATEMENT 

The CALL statement enables the user to insert preestab- 
lished procedures (procedure files) in the control state- 
ment record of a job. A procedure file consists of control 
statements and control language statements organized 
into a routine that is r^teatedly used in jobs submitted by 
the user. Instead of re-creatii^ this routine for succes- 
sive jobs, the user inserts a call to the procedure file. 
When the CALL statement is processed, the [^ocedure file 
is added after the CALL statement in the job's control 
statement record and becomes a part of that record. The 
basic format of the CALL statement is as follows: 



CALLQfn) 
Ifn 



Name of the Ex-ocedure file to be 
inserted in a control statement recwd. 
If a local file with the name Ifn is not 
found, the system does a GET 
internally. 



The name of the procedure file may appear as the first 
statement of the file; howeva, it is an optional reference 
and is not part of the insertion. This name may or may 
not have a terminate. 



Figure 6-2. Resulting Dayfile from GOTO 
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If the user wants control to be initially transferred to a 
statement in the procedure file other than the first, he 



CALL(lfn,S=cec) 



ecc 



Statement identifier of any statement 
in the procedure file (any one of the 
previously explained forms, refer to 
Statement Format) 



Example 1: 



The following procedure file is made into an indirect 
access permanent file. 

DEMO 

COPYBR{,TEMP) 

REPLACE(TEMP=CONTROL) 

GOTO,COMMENT. 

GEIXDEFER) 

COPYSBF(DEFER,) 

GOTO.COMMENT. 

400,GET(CONTROL) 

C0PYSBF(C0NTR0LJ 

COMMENT. END 

The first statement DEMO is the name of the procedure 
file and does not have a terminator. 

A job's control statement record contains the following 
statement. 

CALL(DEMO) 

The following relevant portion of the dayfile results. 

13.25.44.CALL(DEMO) 

13.25.44.COPYBR(,TEMP) 

13.25.45. COPY COMPLETE. 

1 3-25.45.REPLACE(TEMP=CONTROL) 

13.25.45.GOTO,COMMENT 

13,25.45.COMMENT. END 

A job's control statement record contains the following 
statement. 

CALL(DEMO.S=GET) 

The following is the relevant portion of the dayfile that 
results. 

09.11.55.CALL(DEMO,S=GET) 

09.11.56.GET(DEFER) 

09.11-56.COPYSBF(DEFERJ 

09.11.56. END OF INFORMATION ENCOUNTERED. 

09.11.57.GOTO,COMMENT. 

09.11.57.COMMENT, END 

A job's control statement record contains the following 
statement. 

CALL(DEMO,S=400) 

The following is the relevant portion of the dayfile that 
results. 



14.33.21.CALL(DEMO,S=400) 

i4.33.2i.400,GET(CONTROL) 

i4.33.21.COPySBF{CONTROL,) 

14.33.22. END OF INFORMATION ENCOUNTER 

14.33.22.COMMENT. END 



Example 2: 

This example demonstrates the nesting of calls to pro- 
cedure files. Two FORTRAN programs convert English 
units to metric units; the first program converts weights, 
and the second program converts lengths. The following 
job compiles these programs and saves the object code as 
indirect access permanent files. 

METRICS. 

USER Statement 

CHARGE Statement 

FTN(B=WEIG) 

SAVE(WEIG) 

FTN(B=LENG) 

SAVE(LENG) 

7/8/9 



FORTRAN source 
program to conv«-t 
weights 



7/8/9 



FORTRAN source 
program to oonvwt 
lengths 



6/7/8/9 



The following procedure file mal<es a local copy of WEIG 
and executes it, 

WEIGHT 

GET(WEIG) 

WEIG. 

The following procedure file makes a local copy of LENG 
and executes it. 

LENGTH 

GEKLENG) 

LENG. 

These files are made indirect access permanent files with 
the names WEIGHT and LENGTH. 

The following procedure file can call either WEIGHT or 
LENGTH. 

METRIC 
CALUWEIGHT) 
GOTO.COMMENT. 
2LENG,CALL(LENGTH) 
COMMENT. ••END** 



6-4 
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If the control statement record calls this procedure file 
with 

CALIXMETRIC) 

the procedure file METRIC wiU in turn eaU the procedure 
file WEIGHT which wiU initiate execution of the program 
WEIG. An input recOTd of English weights will be 
converted to metric. 

If the cwitrol statement record calls the procedure file 
METRIC with 



CALL(METRIC,S=2LENG) 

the program LENG will be executed, and an input record 
of English lei^hs wiU be converted to metric. 

The expansion of the control statement recra-d by these 
caUs is diagrammed in figure 6-3. The dayfiie resulting 
from CALL(METRIC) is shown in figure 6-4, and the 
da^ile resulting from CALL(METRIC,S=2LENG) is shown 
in figure 6-5. 



Control Statenwnt 
Rflcord 



Procedure File 
METRIC 



Procedure File 
WEIGHT 



CALUMETRIC) 



METRIC 



CALL(WEIGHT) 



I 



WEIGHT 

GET(WEI6) 

WEIG. 



GOTO,COMMENT. 
COMMENT ••END* 



Control Statement 
Record 



Procedure File 
METRIC 



Procedure File 
LENGTH 



CALL(METRIC,S-2LENG) 



I 



l__ 



METRIC 

2LENG.CALULENGTH) 

I 

I 



LENGTH 

6ET(LENG) 

LENG. 



I 
COMWIENT ••END* 



Figure 6-3. Control Statement Record Expanaon with Nested Calls 
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17.32 

17.32 

17 . 32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32 

17.32. 

17.32. 

17.32. 

17.32, 



,3^.METBIC1. 
.35.USER(JC8501,) 

,36.CALL(MErRIC) 
36. CALL (WEIGHT) 
37.GEr(WEIG) 
38.WEIG. 
40. STOP 

^0- .006 CP SECONDS EXECUTION TIME 

41. GOTO, COMMENT. 
41. COMMENT. ••END»» 



41.UEAD, 
41.UEPF, 
41.UEMS, 
41.UECP, 
41.AESR, 
47.ULCP, 32, 



0.002KUNS. 
0.025KUNS. 
1.313KUNS. 
0.599SECS. 
3.107UNTS. 

0.128 KLNS. 



08 

08 

08 

08 

08 

08 

08 

08. 

08. 

08. 

08. 

08, 

08. 

08. 

08. 

08. 



.52.25.METBIC2. 
.52.25.USER(JC8501 ,) 
.52.25.CHARGE(1010,NOS11) 
.52.25.CALL(METBIC,S=2LENG) 
.52. 26. 2LENG, CALL (LENGTH) 
.52.27.GET(LENG) 
.52.27.LENG. 
.52.28. STOP 

.52.28 .006 CP SECONDS EXECUTION TIME 

52. 28. COMMENT. ••END»" 



52. 29. UE AD, 
52.29.UEPF, 
52.29.UEMS, 
52.29.UECP, 
52.29.AESR, 
52.35.UCLP, 35, 



0.002KUNS. 
0.025KUNS. 
1.252KUNS. 
0.563SECS. 
3.050UNTS. 

0.128 KLNS. 



Figure 6-4. CALL(METRIC) Dayfile 



Figure 6-5. CALL(METRIC.S=2LENG) DayfUe 
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ERROR CONTROL 



The system nca-mally terminates job processing if an errcH' 
is generated. However, the user can restrict or suspend 
this error exiting by inswting combinations of the 
following erro- control statements in the job's control 
statement record. 

EXIT 

NOEXTT 



If the user inserts a NOEXIT statement in the job's control 
statement record, error processing is suspended for the 
statements that follow. Error processing will remain 
suspended until the end of the job or until the system 
encounters an ONEXIT statement. With error processing 
sus^nded, the ^stem will attempt to process each 
succeeding control statement no matter how many fatal 
errors are encountered. 



ONEXrr 

The [ff<^ammer inserts an EXIT statement as a reentry 
point in the control statement record, where processing 
can resume instead of terminating when an error is 
geno'ated. If error processing is in effect and a control 
statement produces an errw, the system sequentially 
searches the remaind« of the control statement reewd 
for an EXIT statement. If it finds an EXIT, it resumes 
processing with the statement following the EXIT. If it 
fails to find an EXIT, it terminates the job. If no error 
occurs, processii^ terminates when the EXIT statement is 
encountered (figure 7-1). 



Example 1: 

The following control statements are included in the 
ccHitrol statement rec»d of a job. 

COPYBR{INPUT,INFILE) 
APPEND(BETA,INFILE) 
GET(BETA) 
COPYSBF(BETA,OUTPUT) 

This adds an input record to an existing indirect access 
permanent file. A local copy is made of the extended 
permanent file and printed out. The rdevant dayfile 
entries are as follows: 



© 



PROCESS NEXT 

CONTROL 

STATEMENT 





TERMINATE 



Figure 7-1. EXIT Statement Operation 



13.53.40.COPYBR{INPUTJKFILE) 

13.53.40. COPY COMPLETE. 

13.53.40.APPEND(BETA4NFILE) 

13.53.41.GET(BETA) 

13,53.42.COPYSBF(BETA,OUTPUT) 

13.53.42. END OF INFORMATION ENCOUNTERED. 



Example 2: 

If the user has erroneously punched the first copy 
statement so titat it reads 

COPYBCINPUTJNFILE) 

the dayfile would read as follows: 

13.59.30.COPYBaNPUT,INFILE) 
13.59.30. ILLEGAL CONTROL CARD. 

The job terminates at this point. 



ExampieZ: 

If , in the previous example, an EXIT has been placed after 
the GET 

COPYBdNPUTJNFILE) 

APPEND(BETA4NFrLE) 

GET(BETA) 

EXIT. 

COPYSBF(BETA,OUTPUT) 

the dayfile would read as follows: 

14.02.00.COPYB(INPUT4NFILE) 

14.02.00. ILLEGAL CONTROL CARD. 
14.02.0D.EXIT. 
14.02.00.COPYSBF(BETA,OUTPUT) 

14.02.01. END OF INFORMATION ENCOUNTERED. 
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As soon as the system encountered the illegal statement, 
it sltipped to the EXIT statement and resumed processing. 



13. NOS Reference Manual, Volume 1), since they give the 
machine language representation of his job. 



Example 4: 

If instead of the EXIT, in the preceding example, a 
NOEXIT had been placed ahead of all of these statements 

NOExrr, 

COPYB(INPUT,INFILE) 
APPEND(BETA,INFILE) 
GET(BETA) 
COPYSBF{BETA.OUTPUT) 

the dayfile would read as foUows: 

14.05.44.COPYB(INPUT,INFILE) 

14.05.44. ILLEGAL CONTROL CARD. 
14.05.45.APPEND(BETA,INFILE) 

14.05.45. INFILE NOT FOUND, AT 000121. 
14.05.45.GET<BETA) 
14.05.45.COPYSBF(BETA,OUTPUT) 

14.05.45. END OF INFORMATION ENCOUNTERED. 

Although the first copy statement is illegal, the system 
attempts to ptocess each succeedii^ control statement. 

The address in the job wh^e the system looked for the 
ALPHA reference was 000121. This is important to the 
batch user when he begins taking dumps (refer to section 



Example 5: 

In the following example, two control statements have 
errOTS (COPYB Instead of COPYBR and BATA instead of 
BETA in the GET). A NOEXIT precedes all the state- 
ments, and an ONEXIT follows the APPEND. 

NOEXIT. 

COPYB(INPUT,INFILE) 

APPEND(BETA,INFILE) 

ONEXIT. 

GET(BATA) 

COPYSBF(BETA,OUTPUT) 

The relevant portion of the resultant dayfile is as follows: 

14.17.16.NOEXIT. 

14.17.16.COPY«INPUT,INFILE) 

14.17.16. ILLEGAL CONTROL CARD. 

14.17.16.APPEND(BETA.INFILE) 

14.17.16. INFILE NOT FOUND. AT 000121. 

14.17.16.0NEXIT. 

14.17.16.GET(BATA) 

14.17.16. BATA NOT FOUND. AT 000121. 

Alter NOEXIT, error processing is suspended, and even 
though the COPYB is illegal, the system tries to process 
the APPEND statement. After ONEXIT, error processing 
is again in effect, and the failure to find a permanent flle 
called BATA ends job processing. 



7-2 
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This section describes the use of labeled, magnetic tape 
files. The f ollowii^ control statements are included. 

LABEL 

RESOURC 

The following descriptions and examples introduce mag- 
netic tapes. The full range of tape capabilities under NOS 
is given in the NOS Reference Manual, Volume 1. 



DEFINITIONS 

The Ewogrammer who wants to use magnetic tapes should 
be familisir with the identification and layout of data on 
tapes (figure 8-1). The following paragraphs give funda- 
mental definitions of these features. 



GAP 



BLOCK 



GAP 



TAPE 
TRACKS 





II ;i 


1 •- 




III |i 






1 1 


i • 




1 1 1"" 


**** 1 • 




1 
III 


II * 




■ 1 1 1 1 











PARITY 

'bits 



-FRAME 



Figure 8-1. Magnetic Tape Data Layout 



All the parameters which identify and f^eseribe the layout 
of data on me^etic tapes have defaults. Some of these 
defaults are standard with NOS; others are specified by 
the installation. Defaults are ^nored in this section to 
familiarize the beginnir^ tape user with the fundamental 
parameters. 



DENSITY 

Tlie density of data written on a magnetic tape is the 
number of eliaraeters per lengthwise inch. This is 
measured in bits per inch (bpi) or characters per ii.eh (cpi). 
The user specifies density with the parameter D=den. The 
values for den are the following. 



cien 


Value 


Track Type 


LO 

HI 

HY 

HD 

PE 


200 bpi 
556 bpi 
800 bpi 
800 cpi 
1600 epi 


7 
7 
7 
9 
9 



The examples in this section use the specification D=HY. 



RECORDING. MODE 

Reccffds are written on tape in either binary or coded* 
mode. Binary mode is the format used to store data in 
central memory. This is the 6-bit display code listed in 
appendix D. Binary mode can be used to record any data, 
and since no code conversion takes place, it is usually 
more efficient. Coded mode includes any of the formats 
used to store data on peripheral devices. For 7-traek 
tapes, this can be 6-character external BCD or the 6- 
charaeter subset of ASCII (refer to appendix D). For 9- 
track tapes, this can be S-character ASCII or 8-character 
EBCDIC (refer to appendix A of the NOS Reference 
Manual, Volume 1). Coded mode writes character data 
(program source code, t«ct, card input, information to be 
printed, and so forth); it cannot be used for binary data. 

The user of this guide specifies rec»ding mode by his 
selection of copy statements (refer to section 4). 

The I format for tapes, described in this section, recwds 
in binary mode. Accordingly, the user can employ this 
format for writing and reading any data. 



TAPE TRACKS 

Data can be written on magnetic tape in 7 or 9 parallel 
data paths (tracks), extending lengthwise on the tape. A 
particular model of a tape drive will read and write either 
7-track exclusively or 9-track exclusively; there is no 
interchangeability between the two track types on a sii^le 
drive. 

The user specifies 7-track with the paramet^ MT and 9- 
track with the parameter NT. The examples in this 
section use MT. 



PARITY 

Every tape is written with one track composed of check 
bits called parity bits. The system adds these bits during 
the write operation so that each frame will have an even 
number of bits (even parity) <x an odd number of bits (odd 
parity). The remaining tracks (six for a 7-track tape and 
eight for a 9-tradc tape) will contain user data. When the 
tape is read, each frame is checked for proper parity. If 
any frame fails the test, an error message is issued to the 
dayfile, and the system rereads the block in which the 
errw occurred. This reread is repeated a number of 



60436300 A 



8-1 



times. If the error was transient and the frame passes the 
parity test, reading continues; otherwfee, reading termi- 
nates. 

A 7-track tape uses even parity for coded recor<te and odd 
parity for binary records. A 9-track tape uses only odd 
parity. 

Ordinarily, the user has no control over parity but should 
understand its significance to interpret tape error mes- 
sages. 



BLOCKS 

A tape drive needs a short length of tape for stc^and-go 
operations. Hence, the drive cannot position to individual 
characters but must transfer data in parcels to and from 
memory where the individual data items can be addressed. 
These parcels are called blocks. Blocks are spaced on 
tape with the necessary blank gaps between them. Block 
length or size is specified in characters/block. The length 
of a block may be fixed or variable, depending upon the 
format used. 



VOLUME 

In tape terminology, a volume is the set of all files on one 
reel of tape. This may be an empty set, or the set may 
occupy all or part of the reel. There can be but one 
volume per reel; hence, the term is often used as a 
synonym for a reel of tape. 



VOLUME SERIAL NUMBER 

A volume serial number (VSN) is one to ax alphanumeric 
characters that identify the set of files on a single reel of 
tape. A VSN is handwritten on the outside of a reel 
(external label) and, for labeled tapes, entered in the first 
internal label of the tape. If an installation is issuing 
tapes to users, it will specify VSNs. These installation 
tapes will have the VSN on an external label and, If 
labeled tapes are being used, they will be blank-labeled. 
A tape is blank-labeled when the format of the first 
internal label is written on the tape with all entries 
except the VSN blank. If the user has his own tapes and is 
specifying his own VSNs, he will handwrite his VSNs on the 
outside of the reels he submits with his jobs. If the tape is 
to be labeled, he will request the operator to blank-label 
it with the VSN specified. Customarily, this request is on 
a form that accompanies the job. Some installations 
permit users to blank-label their tapes with the BLANK 
control statement (refer to the NOS Reference Manual, 
Volume 1). 

The system uses the VSN on the internal label of a labeled 
tape to assign that reel to a user's job via the Ifn the user 
specifies on a LABEL control statement. During the 
remainder of job processing, control statements that 
contain this Ifn access the reel of tape with the associated 
VSN. The Ifn is released when the job terminates; the 
VSN remains with the reel until specifically changed. 



TAPE LABELS 

A NOS-labeled tape uses internal tape labels for identifi- 
cation and indexing. Each label consists of 80 characters. 
The first label is the volume header label which is written 
at the beginning of the tape. It contains the VSN and 
owner identification (user number/family name) for the 
tape. Following this, every file copied to the tape will 
have a file header label before the first block of data and 
an EOF label after the last block of data. These file 
delimiting labels can contain indexing parameters to 
access individual files by name and/or sequence number. 
Indexing of multifile tapes is explained in the NOS 
Reference Manual, Volume 1. 



TAPE FORMAT 

The format of a magnetic tape is the physical layout of 
data on the tape. This can include block size, mode 
(binary/coded), internal tape labels, record and file de- 
limiters, and special features of data definition. Eight 
formats are presently available under NOS (refer to 
section 10 of the NOS Reference Manual, Volume 1). Any 
one format is specified on a tape control statement with 
the keyword F=format; the examples in this section use I 
format This format is the most reliable since, on read 
operations, the system checks the number of bytes read 
with the number expected and uses this check to detect 
incomplete or missing blocks. 



HOW TO CREATE A LABELED TAPE 

The user creates a labeled tape with the following basic 
version of the LABEL statement. 

LABEL(lfn,VSN=vsn,D=den,tr,F=format,W) 

Ifn Local file name temporarily given to 

the data on the tape (whether it is 
recorded or is about to t>e written). 
This parameter must come first; the 
others are order-independent. 

vsn Identifies the physical reel of tape. It 

is used to assign the reel of tape to the 
job. 

den Tape density (LO, HI, HY, HD, or PE). 

tr Track type (MT or NT). 

format Tape format in which data will be 
written on the tape (I, SI, X, S, L, E, B, 
orF). 

W Specifies the writing of internal file 

identifying labels by the system. 

When the LABEL statement is processed, the system 
determines which tape drive has a tape mounted with the 
^ecified vsn and automatically assigns that tape to the 
job via the Ifn in the LABEL statement. 
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A user has a reel of tape that has been blank-labeled with 
VSN=MAG5. He wants to «^y a file from his input deck 
to this tape. He includes the followir^ statements in the 
deck. 

LABEL(TFILE.VSN=M AGS ,D=HY ,MT,F=I, W) 
COPYBR(,TFILE) 

When job jH-ocessing encounters the LABEL statement, the 
system automatically assigns the reel of tape identified 
with VSN=MAG5 to this job via the name TFILE. Data 
written on this tape will be recwded at a density of 800 
bpi em a 7-traek unit. Since I format fe specified, the data 
wfll be written in binary mode. Binary records on 7-track 
have odd parity. 

The COPYBR statement copies an input record to the 
tape. Subsequent control statements in the same job can 
access this tape record with the name TFILE. These job 
steps are recorded in the job's dayfile as follows: 

LABEL(TFILE,VSN=MAG5.D=Hy,MT,F=I,W) 
MT53, ASSIGNED TO TFn.E , VSN=MAG5 , 

COPYBR(,TFILE) 
COPY COMPLETE. 

MT53 ^ecifies that the tape is mounted on the magnetic 
tape drive with equipment number 53. 

Later in the same job, this file is printed with the 
foUowing statements. 

REWINIKTFILE) 
COPYSBF(TFILEj 



HOW TO ACCESS A LABELED TAPE 

The user can access an existing labeled taipe with the 
following format of the LABEL statement. 

LABEL(lfn,VSN=vsn,D=den,tr,F=format,R) 

R Specifies read-label which initiates a 

^stem comparison of the present val- 
ues in the internal tape labels with the 
parameters on the LABEL statement. 
If the comparfeon fails, the job aborts. 

After processing this statement, the tape is attached to 
the job via the local file name Ifn. Subsequent control 
statements in the same job can read or write information 
on this tape. 

If a W is included in the LABEL statement instead of an 
R, this will create a new labeled tape, and all the ecisting 
data will be destroyed. 

Before anything can be written on a reel of tape, a write 
ring must be inserted. The hardware requires an explicit 
action (ins^tion of the write ring) before it will record 
data on a tape to guarantee that existing data will not be 
accidentally written over. To ensure that this ring is 
inserted, the user may include the optional parameter 
PO=W. If the PO=W parameter fe included and the tape is 
mounted without the write ring, job processing wfll be 
su^ended until the operator remounts the tape with a 
ring. If W is specified, PO=W is not needed to enforce 
ring in. 

The user can ensure that the write ring is left out so the 
tape is not accidentally written on by including the 



tape is mounted with a write ring inserted, job fwoeessing 
is suspended until the operatcx* removes the ring. 



Example: 

To access the tape file created in the previous example 
and add information from the INPUT file, the following 
control statements are included in a subsequent job. 

LABEL(DEM02,VSN=MAG5,D=HY,MT,F=I,PC=W,R) 

SKIPEI(DEM02) 

C0PYBF(,DEM02) 

The tape file is given a new Ifn (DEM02), but the vsn for 
the reel (MAGS) remains the same. DEM02 refers to the 
data on this reel, and MAGS refers to the physical reel of 
tape. 

If the SKIPEI statement had not been included, the ii^ut 
record would have been copied over the old information. 



HOW TO COPY FROM ONE TAPE TO 
ANOTHER 

The user can copy one tape to another by includii^ two 
LABEL statements (one for each tape) in the job. 
However, a RESOURC statement must come before the 
second or both LABEL statements. The RESOURC 
statement is required whenevw two or more tape drives 
will be used concurrently. The format of this statement fe 
as follows: 

RESOURC(rt=u) 

rt MT for 7-track or NT for 9-traek 



u 



Number of tape drives to be used by the 
job concurrently 



Example: 



A job uses the following control statements to copy one 
tape to another and verify the copy. 

RESOURC(MT=2) 

LABEL{DEM03,VSN=MAGT1,D=HY,MT,F=I,R,P0=R) 

LABEL(DEM04.VSN=MAGT2,D=HY,MT,F=I,W) 

COPYEI(DEM03,DEM04) 

VERIFY(DEMO3,DEMO4,R,N=0) 

The RESOURC statement specifies two 7-track tape 
drives for the job. The first LABEL statement assigns the 
source of the copy to one drive, the R specifies the 
cheekily of labels, and PO=R ensures that DEMOS is used 
only for reading and is not written on. The second LABEL 
statement assigns the reel of tape to receive the copy, 
and W specifies the writii^ of labels. After the copy is 
made, it is verified. The dayfile entries for this sequence 
are as follows: 

RES0URC(MT=2) 

LABEL(DEM03,VSN=MAGT1,D=HY,MT,F=I,R) 
MT53, ASSIGNED TO DEM03 , VSN=MAGT1 . 

LABEL(DEM04,VSN=MAGT2,D=HY,MT,F=LW) 
MT54, ASSIGNED TO DEM04 , VSN=MAGT2 . 

COPYEI(DEM03,DEM04) 

COPY COMPLETE. 
VERIFY(DEMO3,DEMO4,R,N=0) 

VERIFY GOOD. 
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TAPE ERROR MESSAGES 

Tape errors rssult from physical causes (which may be 
transient) or incorrect formats (label missing, improper 
block length, and so forth). When NOS encounters a tape- 
related error, it issues a 3- or 4-line message to the job's 
dayfile. The following message is typical. 

MT,C13,03,MT2 .RD,53,SO,GS4203. 
MT,C13,O100001000200000Q0502000000000120 
MT,C13,FO7,I00.B000000,L0050,P00000000. 
MT,C13,E30,H4063,540, STATUS. 



The following entries are of interest to the batch user. 



RD 



S3 



Fourth line: STATUS 



First Une: MT2 



Volume serial number of the 
reel of tape. 



Read operation; WD indicates 
a write operation. 

Equipment numl>er of the tape 
drive. 

Indicates that recovery was 
not possible with this attempt. 
If in any of these attempts, 
recovery is successful, STA- 
TUS will be replaced with RE- 
COVERED, If recovery fails 
after a number of attempts, 
STATUS is replaced with the 
error description. Typical en- 
tries are WRONG PARITY and 
BLOCK SEQUENCE ERROR 
(refer to the NOS Reference 
Manual. Volume 1). 
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BATCH INPUT FROM A TERMINAL 



This section describes deferred batch processing in which 
a user types the line images of a batch j<* at a time- 
sharing terminal and submits them for processing as a 
batch job. This section also describes conva-sational 
batch processing in which the user enters control state- 
ments from a time-sharing terminal to be processed one 
at a time in the same manner as time-sharing commands. 
The following control statements are included in the 
descr^tions. 

SUBMIT 

ENQUIRE 

DAYFELE 

ROUTE 

This section assumes the user is familiar with terminal 
c^>eration. Such terms as line number and primary file are 
used without definition. The mechanics of terminal usage 
are explained in the NOS Time-Sharing User's Guide and 
NOS Time-Sharing Usw's Reference ManuaL 



I NOTE I 

In this section, user entries at the terminal 
are indicated with lowercase letters, and 
system responses are indicated with upper- 
case letters. 



DEFERRED BATCH 

The iBer may create a deferred batch job during a time- 
sharing session at a terminaL He types the job statements 
with reformatting directives (refer to Reformatting Di- 
rectives), as required. If input records are to be used, 
tSiey are typed after the statements. This sequence of 
line images and embedded reformatting directives consti- 
tute the submit file. The submit file enters processii^ 
when the user types the SUBMIT statement at the 
luminal. 

Output from job processing can go to a fainter, it can be 
made a permanent fUe which may be displayed at the 
terminal after job processing, «• it can be dropped. 
Output may be dropped when the user is merely checking 
the dayfiie to see how the job ran. When it runs 
satisfactOTily, output can be initiated (refer to DAYFILE 
Statement). 

TTie terminal user may include line numbers to make 
correetiMis before submitting the job; however, the 
submit file can be constructed und» text mode (refer to 
the Time-Sharii^ Reference Manual) or with the Text 
Editor (refer to the NOS Text Editor Reference Manual). 



The structure of the submit file is explained under 
Reformatting Directive. Entering the submit file for 
processing is explained under SUBMIT Statement. Moni- 
toring deferred batch processing is outlined under EN- 
QUIRE Statement and DAYFILE Statement. 



REFORMATTING DIRECTIVES 

The reformatting directives described in this guide are 
essential for establishing the limits and divisions of a 
batch job, inserting existing files, and deleting or retain- 
ing line numbers. Additional directives are described in 
the NOS Reference Manual, Volume 1. 

All reformatting directives begin with a / to distinguish 
them from control statements; they do not have a 
terminator. 

The terminal user signals the beginning of a deferred 
batch job by typing: 

/JOB 

He follows this with the job statement, USER statement, 
and CHARGE statement (if requirecO. Typically, the first 
four statements are as follows: 

/JOB 

job statement 
USER statement 
CHARGE statement 

Since multipunching is impossible on a terminal keyboard, 
special directives are available to signal the EOR and the 
EOF. The user specifies an EOR and EOF by typing: 

/EOR 

/EOF 

An EOI directive is not needed with a deferred batch job. 

The system wfll remove line numbers by default when it 
begins processing a deferred batch job. However, the user 
can retain line numbers for specific segments of the file 
by inserting the following directive. 

/NOSEQ 

The lines that follow this directive will retain their line 
numbers. If lat« in the file the user wants to return to 
the default, he inserts the following directive. 

/SEQ 

The system will remove the line numbers from all lines 
that follow this directive. 
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The user can insert an existing file in the sequence of 
lines that make up a submit file with the following 
directive. 

/READ,lfn 

The parameter Ifn can be the name of a local file or a 
permanent file. If it is a permanent file, the system will 
automatically perform a GET or ATTACH. 

Figure 9-1 shows the reformatting of a submit file. The 
left side of the figure shows the file as it is typed at the 
terminal; the right ade shows the reformatted file that 
enters processing. 



SUBMIT,lfn,q 

No terminator is needed, bat the parameters are order- 
dependent. The Ifn parameter is the name of the submit 
file. By default, Ifn is the primary file. The q parameter 
specifies the disposition of output as foUows: 

B Output goes to the central dte printer. 

N Output is dropped at job termination, de- 

fault from a time-sharing terminal. 

E Output goes to a remote batch terminal. 



Tha lubmit file 
« typed in 

00010/JOB 

00020 JONES,Tia 

00030 USER itatinMit 

00040 CHARGE nrarmnt 

00060 BASIC 

00060 /EOR 

00O70 /N<»EQ 

00080 REM PROGRAM TEST 



BASIC 

KMIfC* 

protraia , 

00290 END -J 

00300 /SEQ 

00310 /EOR 

00320 I 1 

input fof ' 

BASIC prognm , 

0OS90 •• 1 

00600 /EOF 



Th* nforinittMi 
Mtfamit fil* that 
ttntmtan pracranifl 



JONESJia 

USER stttwiwnt 

CHAR6E 

BASIC. 

fnd■o^r•canl 

00080 REM PROGRAM TEST 

BASIC 




00290 EMO 

andHjf-facocd 

i" — — — -. — .. — — -^ 

input for I 

BASIC profram i 

I. - I 

•fid-«flii« 



Figure 9-1. Reformatting a Submit File 



SUBMIT STATEMENT 

The time-sharing user enters the SUBMIT statement to 
initiate batch processing of a submit file he has created. 
The basic format of the statement is as fcdlows: 



Example: 

The following lines constitute a submit file the user 
creates and submits from a terminal. User entries are 
lowercase, and system responses are uppercase. 



new.demo 


READY 


• 


auto 




00100 


/job 


00110 


myjob. 


nni^n 


us€*^efd25 e'^ 


00130 


charge(58n2) 


00140 


c<!pybf(,newlist) 


00150 


r^>lace(newlist) 


00160 


/eor 


00170 


item one 


00180 

• 


item two 


00320 


item last 


00330 


/eof 


00340 


•DEL* 


submit 





The abbreviated form of the SUBMIT statement implies 
two defaults, the submit file is the primary file (DEMO) 
and output will be dropped (N). Any one of the following 
versions of the statement accomplishes the same thing. 

submit,demo,n 

submit„n 

aubmit.demo 

submit 

As soon as the SUBMIT statement is processed, the system 
prints the time and the 7-character Job name. A typical 
response is as follows: 

11.12.01. AKQIFIA 
READY. 
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ENQUIRE STATEMENT 

After a user has entered a submit flle for processing, he 
can track the prc^ess of the job with the following 
ENQUIRE statement. 

ENQUIRE,JN=job 

job Last three characters of the name the 

system displays as soon as the SUBMIT 
statement is processed; no t^minator is 
needed 

The following system responses are possible. 

jobname IN INPUT QUEUE 

jobname EXECUTING 

jobname IN ROLLOUT QUEUE 

jobname IN PRINT QUEUE 

jobname NOT FOUND 

The last response indicates that processing is complete. 
The jobname parameter is the 7-character job deagnation. 

Af tor creating a submit file and entering it for processing 
with 

submit„b 

the ^stem responds as follows: 

17^5.19. AKQIBIN 
READY. 

The user then types: 

enquirejn=t>in 
or 

enquire Jn=alcqibin 
The system responds as follows: 

AKQIBIN IN PRINT QUEUE, 
llie usv waits a moment and then types: 

enquirejn=bin 
The system responds as follows: 

AKQIBIN NOT FOUND. 

The user now knows his job has completed processing and 
can pick up his printout. 

DAYFILE STATEMENT 

The time-sharing user can insert the DAYFILE statement 
into a submit Hie and obtain a copy of most of the dayflle 
resulting from processing. This enables the user to rerun 
and trmibledioot a deferred batch jc^ without printouts. 
The DAYFILE statement is used in conjunctim with the 
REPLACE statement as follows: 



DAYFILEOfn)^ 
KcPLACEufn) 

Ifn Us»-supplied local file name for the 

daynie 

If these statements are included in a submit file, a copy of 
the resulting dayfile from the beginning (job statement) to 
the DAYFILE statement will be made a permanent file 
with the name Ifn. The user can obtain a listing of this 
copy with the following statements. 

GET,lfn 
LNH,F=lfn 



or 



OLD,lin 
LNH 

l^e following submit file c^tains a copy of a compiled 
COBOL program that indexes the random name list 
included with the file. 



00100 


/job 


OMIO 


«fd. 


00120 


usertefd25,d) 


00130 


charge,S823,693N55, 


00140 


get(alfa) 


00150 


alfa. 


00160 


dayfile(day) 


00170 


replac^day) 


00180 


/e» 


00190 


smith,a.3. 


00200 

• 


greenj.e. 


00340 


jonK,r.t. 


00350 


/eof 


SUBMn 




13.53.39.AKQIBGL 


READY 


. 



The us» verifies that processing is complete and obtains a 
dayfile listing as foUows: 

get.day 
lnh,f=day 

13.06.08.EFD. 

13.06.08.USER(EFO2S.) 

13.06.08.CHARGE,8S23,693N5S. 

13.06.09.GET(ALFA) 

13.06.09.ALFA. 

13.06.14.SOURCE UNE 28 

13.06.14.S TART COBOL SORT 

13.06.14. 

13.06.14. 

13.06.15.93 RECORDS RELEASED 

13.06.15.93 RECORDS RETURNED 

13.06.15.E ND COBOL SORT 

13.06.15.DAYFILE{DAY) 

The user can make the saving of the dayfile dependent 
upon error processing by adding the following statements 
at the end of the control statement record. 

DAYFILEdfn) 

REPLACEdfn) 

EXIT 

DAYFILEdfn) 

REPLACEdfn} 
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The first two statements provide a dayfile if no error was 
detected. In that case, the EXIT causes job termination. 
The last two statements will be processed only if an error 
occurs. In that case, any error in the previous statements 
will initiate a skip to EXIT and the processing of the 
remaining statements. 



LISTING BATCH OUTPUT AT A TERMINAL 

The output from processing a deferred batch job can be 
listed at a terminal rather than printed by including the 
following statement in the centred statement record of 
the submit flle. 

REPLACE(OUTPUT=pfn) 

pfn Us»-given name of the permanent file 

that is a copy of the job's OUTPUT file 

The dayfile wHl not be included. If the user wants the 
dayfile, he should include a DAYFILE statement ahead of 
the REPLACE statement. 



Example: 

The following submit file compiles and executes a BASIC 
program which obtains its input from the submit file. 



00100 


/job 


00110 


smith. 


00120 


usaKs221,sm} 


00130 


charge(923.92nl} 


00140 


basic. 


00150 


replace(output=display) 


00160 


/eor 


00170 


/noseq 


00180 


rem basic program 


00190 


input bl,b2.b3 


00200 


print b3,b2,bl 


00210 


end 


00220 


/seq 


00230 


/ecr 


00240 


11111,22222,33333 


00250 


/eof 



After the user verifies that processing is complete, he 
types: 

get.display 
lnh,f=display 

He then receives the following listing at the terminal. 

1 BASICXX BASIC 3.1 

76316 77/01/27. 15.28.50. PAGE 1 



00190 REM BASIC PROGRAM 

00200 INPUT B1,B2,B3 

00210 PRINT B3,B2,B1 

00220 END 



33333 



22222 



11111 



CONVERSATIONAL BATCH 

Conversational BATCH refers to the batch subsystem, one 
of the subsystems available under time-sharing operation. 
In the batch subsystem, the user can enter batch control 
statements and time-sharing commands. Like a time- 
sharing command, each batch statement entered is im- 
mediately processed. 

The user enters the batch aibsystem by typing: 

batch 

Tlie system responds as follows: 

$RFL,0. 
/ 

RFL refers to the running field length for the entries that 
follow. Zero indicates that the system will determine the 
field length for each entry. In most eases, the user need 
not change this (refer to the NOS Reference Manual, 
Volume 1). 
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command after the slash. A terminate^' is not required 
except with control language statements. When the user 
{^esses carriage return, this entry is processed. If the 
processing produces a message or listing, this follows the 
entry. A new slash will appear, and the user can type 
another statement or command. The user exits from the 
batch subsystem by typing the name of anothw time- 
sharing sub^stem (NULL, FTNTS, BASIC, EXECUTE). 

In conversational batch, the time-sharing user is no longer 
restricted to time-sharing commands and can use t>ateh 
control statements such as the copy statements, file 
positioning statements, and the ROUTE statement. The 
ROUTE statement has the following format. 

R0UTE(lfn.Pj,P2,~.Pn) 

Ifn Name of a file to be routed to some device. 

pj Specifications of destination, data format, 
and print forms (refer to the NOS Reference 
Manual, Volume 1). The following options 
are frequently used. 



fL 




Disposition Code 


DC=XX 


xx. 






LP 


Print on any prints 




SB 


Punch system binary 




PU 


Punch coded 


Pi 


XX 


Ext^nal Characterfetics 


EC=xx 





ASCn Punch Ascn 
026 Punch 026 mode 
029 Punch 029 mode 



Esffim'^le: 

The following entries in a time-sharing session obtain a 
local copy of a permanent file called INVTORY, make a 
copy of the 23rd recca-d, and route that rewyd to any 
printer. The user then picks up the Ea'intout of the record. 

new,text 

READY. 

batch 

$RFL,0. 

/get,invtc8y 

/skiEH',22 

SKIPR,22. 

/copyte'.invtory.printl 

COPY COMPLETE. 
/rewind,printl 
$REWIND,PRINT1. 
/route,printl ,de=lp 

ROUTE COMPLETE, 
/dayfile 

15,16.59.$CHARGE,966,N24. 

15.17.24.0LD,INVTORY. 

15.18.21.NEW,TEST. 

15.18.27.$RPL,0. 

15.18.56.GETJNVTORY. 

15.19.0SJSKIPR,22. 

15.19.43.COPYBR,INVTORY,PRINTl. 

15.19.44. COPY COMPLETE. 

15.19.57.$REWIND,PRINT1. 

15.20.ll.ROUTE,PRINTl.DC=LP. 

15.20.14. ROUTE COMPLETE. 

15.20.29.$DAYFILE, 

USER DAYFILE DUMPED. 

SKIPR, COPYBR, and ROUTE batch control statements 
are available to the time-sharing user only xmdet conver- 
sational batch. The printout initiated with ROUTE does 
not have a dayfile. If the time-sharing DAYFILE 
command is included, it gives the sequence of command 
and control statement processing from the CHARGE to 
the DAYFILE statement 
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GLOSSARY 



CHARGE 
NUMBER 



COBOL 



COMPILER 



CONTROL 
LANGUAGE 



DEFAULT 



DEFERRED 
BATCH 



DIRECT 
ACCESS FILE 



FAMILY NAME 



FILE 



ADDRESS The location of a word in memory. The CONVERSA- 

loeation is deagnated by number or TIONAL BATCH 

symbolic name. 

BASIC The Beginner's All-purpose Symbolic In- 

struction Code, a higher-level language 
originally deagned and implemented at 
the Dartmouth College Computation 
Center. Programs written in a h^her- 
level language have to be translated 
(compiled) into object code (machine 
language) before they can be executed. 

BATCH JOB A sequence of control statements and 

optional programs and input data that 
are submitted as a self-contained unit 
and processed without user interven- 
ticai^ 

CATALOG Each user has a catalog of his perma- 

nent files that is maintained by the 
system. Whenever he creates, modifies, 
OT purges one of his permanent files, 
the system updates his catalog to re- 
fleet that action. 

An alphanumeric identifier the installa- 
tion uses to allocate charges to individ- 
ual users for system usage. 

common Business Oriented Lai^J^e. 
This higher-level language simplifies 
the prt^ammir^ of business data appli- FORTRAN 

cations. The format of programs writ- 
ten in this lar^ut^e is similar to simple 
English sentences. These programs 
must be translated (compiled) into ma- 
chine language before they can be 
executed. 

A system product that translates source 
code pr<^ams into object code; that is, 
machine language (compilers are avail- 
able for FORTRAN, COBOL, and 
BASIC). 

A set of statements which the user can 
insert into the control statement record 
of a job to initiate skips, conditional 
transfers, and iterations in the process- 
ing of the statements. It also affords 
the capability of setting and di^laying 
software registers, as well as calling 
procedure files. 

CONTROL The first record of every batch job. 

STATEMENT This record contains all the control 
RECORD statements that specify the tasks that JOB FILE 

the system is to perform. 



HIGHER-IEVEL 
LANGUAGE 



INDIRECT- 
ACCESS FILE 



INPUT FILE 



The BATCH subsystem available under 
time-sharing operation. This subsystem 
allows the time-sharing user to enter 
batch control statements, as well as 
time-sharing commands, and obtain an 
immediate response to each entry. This 
distinguishes it from the other forms of 
batch in which statements are sub- 
mitted and processed as a group. 

A value supplied by the system when 
the user omits its specification from a 
parameter list on a control statement. 

A batch job typed at a time-sharii^ 
terminal or included within another 
batch job and submitted for processing 

as a s^-contained units 

A permanent file on mass storage that 
is accessed without an intermediate 
local copy being made. 

A designation that the installation may 
give to a group of permanent file 
devices. 

A contiguous coUeetion of information 
that is accessed by name. It is de- 
limited by a BOI and an EOL It may be 
further divided into recwds. 

FORmula TRANslation, a higher-level 
lai^age consisting of symbols and 
statements that can be used to create a 
program closely resembling mathemati- 
cal notation. This program must be 
translated (corapileefl into machine 
language before it can be executed. 

A prc^ammii^ lar^age written with a 
defined set of mnemonic words and 
translated (compiled) into machine 
language for execution (for example, 
BASIC, COBOL, and FORTRAN). 

A permanent mass storage file that can 
be accessed only by making a copy that 
is local to a particular job. When the 
job terminates, the copy is dropped, but 
the OTiginal remains. 

The system-defined file which contains 
the entire job the user submits for 
processing. It is also known as the job 
file. 

Refer to INPUT FILE. 
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JOB STATE- 
MENT 



LOCAL 



LOCAL BATCH 



LOCAL FILE 



OBJECT CODE 



ORDER- 
DEPENDENT 

ORDER-INDE- 
PENDENT 



OUTPUT FILE 



PARITY 



PASSWORD 



The first control statement of a batch 
job. It identifies the job and inay 
specify a time limit and/or a memory 
limit. 

Refers to data that exbts only during 
the processing of a single job and that 
can only be accessed by that job. 

A batch job submitted at the central 
computer site. 

A file copy created during the f^ocess- 
ing of a single job by a copy statement, 
program, or GET. When the job termi- 
nates, the copy is dropped. 

The machine language version of a 
program that has been translated (com- 
piled) from source code written in an 
ordinal high»-level language. 

Parameters in a control statement that 
must aK)ear in a specified order. 

Parameters in a control statement that 

TTIflV flf>rw>Ai* in flnv At>H<>i* Ka/«aiieA fhav 

rf ^tTr -^ — — - —J — — — , .w.»..w *.*wj 

are specified with keywords. 

The system-defined file which contains 
all the output from job processing. It is 
also known as the print file. 

In writing data, an extra bit is eithw 
set or cleared in each byte so that 
every byte has eith« an odd number of 
set bits (odd parity) or an even number 
of set bits (even parity). Parity is 
checked on a read for error detection 
and possible recovery. 

A password is either an alphanumeric 
value the user may have added to his 
user number to increase the security of 
the user number or an alphanumeric 
value the user may add to one of his 
permanent flies with the PW parameter 
to increase the security of that file. 



RECORD 
UNIT (PRU) 



PERMANENT 
FILE 

PRINT FILE 



PROJECT 
NUMBER 



RECORD, 
LOGICAL 

REMOTE 
BATCH JOB 

SEPARATOR 



SYSTEM 
RESOURCE 
UNIT (SRU) 

TERMINATOR 



USER 
NUMBER 



The physical structure of a file as 
determined by the stwage medium. For 
mass storage, a PRU is 64 central 
memory words (640 characters); for 
magnetic tape, the size of the PRU 
depends upon the tape format. 

A file retained on mass storage until it 
is specifically purged. 

An OUTPUT file containii^ data to be 
printed at a central site line printer. 

An alphanumeric identifier the installa- 
tion uses to allocate charges for system 
usage to individual projects. 

A user-defined subdivision of a file. 



A job submitted from a remote batch 
terminaL 

A character used to separate param- 
eters in a control statement. 

c\ prcgraiu wrivten in 
language (FORTRAN, BASIC, or 
COBOL) which must be translated 
(compiled) into object code (machine 
language) before it can be procesed. 

An accounting unit that is a composite 
of central processor time, I/O activity, 
and memory used. 

The character that must end every 
control statement included in a local 
batch, remote batch, or deferred batch 
job. 

An alphanumeric identifier assigned to 
a user which uniquely identifies that 
mec. The user must specify this 
identifier on his USER statement before 
he can gain access to the system. 



A-2 



80436300 A 



DAYFiLE 



B 



The ^stem E^jpeids a history of control statement 
processing to the OUTPUT file of ev»y job. This is called 
the dayfile. It begins with a heading that gives the 7- 
charaetw job name, the date, emd the installation identifi- 
cation. This heading is followed by a list of all ccHitrol 
statements processed by the job. Comments and die^- 
nc^tics are added where applicable. Every line begins 
with the time at which the entry was made- The time is 
in the format hh.mm.ss.. At the end of the dayfile is a 
list of the resources used by the job. Possible entries are 
as follows: 

UEAD Application charge activity in kilounits. 

This is an overhead charge added to 
each job. 

UEPF Permanent file activity for the job in 

kilounits. This activity includes the 
permanent file operations initiated by 
the statements SAVE, REPLACE, GET, 
DEFINE, and so forth. 

UEMS Mass staeage activity for the job in 

kilounits. This activity includes read 
and write operations, opening and clos- 
ing of flies, and so forth. 

UEMT Magnetic tape activity for the job in 

kilounits. This activity includes read 



and write operations, opening and clos- 
ing of files, and tape positioning. 

UECP Central processor time in seconds. 

AESR System resource units (SRUs) used by 

the job. 

UCLP The number of lines printed given in 

kilolines. 

The value of a kilounit is determined by the installation. 
The SRU is an acccnintii^ unit that is a composite of 
central Ewocessw time, I/O activity, and memory used. 

The user can save an abbreviated version of the dayfile in 
a separate file by including the DAYFILE control state- 
ment in his job's e<»itrol statement record. This version of 
the dayfile begins with the job statement and ends with 
the DAYFILE statement. 

The DAYFILE statement can also be entered under tlie 
BATCH subsystem in a time-sharing operation from a 
terminaL This produces a history of time-sharing activity 
rather than job [»'ocessing (refer to section 9). 

A batch job submitted as a card deck is shown on the left 
side of figure B-1. The dayfile resulting from processing 
of the job is shown <xi the right side. 



fas; 

DAYDEMO. 

DSER(ED25,ED) 

CHARGE(5822,NOS5) 

NOEXIT. 

FTU. 

LGO. 

LIMITS. 

CATLIST. 

GET(FILE5) 

COPYSBFC FILES,) 

7/8/9 

r ] 

! FOHTRAN progpam | 

I I 

I I 

7/8/9 

I 1 

[ data for the [ 
I FORTRAN program i 

!__ ._ I 

6/7/8/9 



jobname. yy/min/dd. 



installation ID. 



08. 32. 50. DAYDEMO. 

08.32.50.USER(ED25,ED) 

08. 32. 50. CHARGE (5 822, N0S5) 

08. 32. 50. NOEXIT. 

08.32.51.FTN. 

08.32.52. .047 CP SECONDS COMPILATION TIME 

08. 32. 52, LGO. 

08.32.52. STOP 

08.32.53. .008 CP SECONDS EXECUTION TIME 
08. 32. 54. LIMITS. 

08. 32. 54. CATLIST. 

08.32.54. CATLIST COMPLETE. 
08.32.54.GET(FILE5) 
08.32.54.COPYSBF(FILE5,) 

08.32.54. END OF INFORMATION ENCOUNTERED. 

08. 32. 55. UEAD, 0.002KUNS. 

08. 32. 55. UEPF, 0.019KUNS. 

08. 32. 55. UEMS, 1.923KUNS. 

08. 32. 55. UECP, 0.618SECS. 

08. 32. 55. AESR. 3.371UNTS. 

08. 35. 03. UCLP, 34, 0.48 KLNS. 



Figure B-1. Batch Job on Cards and the Resulting Dayfile 
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RESOURCES AVAILABLE TO THE USER 



The user can obtain a listing of the maximum system 
resources that the installation has allotted to him by 
including the followii^ ccmtrol statement in a job. 

LIMITS. 

The output from the job will contain a listing of resource 
limits for the user number. If a value of UNLIMITED is 
specified fca- a particular resource, the user has no 
restriction on usage of that item. If the value is SYSTEM, 
then this is a default specified by the installation. 
Numeric values are decimal unless followed by a B to 
indicate octal. 



Example: 

A user with user number EFP2511 c4)tains the following 
listing of his resources. 



LIMITS. 



yy/mm/dd. hh.mm.ss. 



'D2511 


2511 y 


AB=, 




AB=. 




AB=, 




AB=. 




MT = 


3, 


RP = 


2. 


TL = UNLIMITED, 


CM = 


2037B, 


NF = 


40, 


DB = 


10. 


FC = 


SYSTEM, 


CS = 


32768. 


FS = 


SYSTEM, 


PA =EVEN 




RO = 


system! 


PX =HALF 




TT =TTY 




TC = STANDARD 


IS = NULL 


) 


MS = 


12800, 


DF = 


464, 


CC = 


464, 


OF = 


4, 


CP = 


2112, 


LP = 


31232, 


EC = 


OB, 


SL = UNLIMITED. 


CN=, 




PN = 


» 


DS = 


512, 



AW = 00000000000000000415 



The first line gives the current date and time the listing 
was produced. The second line gives the user number, 
user index, date when validation for this user was first 
established, and the date when vetlidation for this user was 
last modified. 

The fields are defined as follows: 

Description 

Answerback identifier (1 to 10 alpha- 
numeric characters). Terminals with 
answerback capability automatically 
send this identifier to the ^stem when 
a user logs in. The system uses the 
answerback to determine if the Ic^-in is 
from a legal t»minaL Each user can 
have up to four terminal answerback 
identifiers. In this example, all four are 
blank implying the installation is not 
using the answerback capability. 

MT Maximum number of magnetic tapes the 

user can have assigned to his job at one 
time. The user in this example can 
have three. 

RP Maximum number of auxiliary devices 

the usOT can have assigned to his job at 
one time. An auxiliary device is a self- 
contained permanent file device that is 
not part of a system configuration of 
devices (family). This example ceci- 
ties a limit of two. 

TL Maximum amount of central |»-ocessor 

time available for any (me of the user's 
job steps. In this example, there is no 
limit. 

CM Maximum number of central memory 

words the user may request for any one 
job. This is the maximum field length 
his job can have. The specification is 
given in multiples of lOOB words. The 
value 2037B implies 203700 octal words 
of memory, which is 67520 decimaL 

NF Maximum number of files the user can 

have with one job at one time. The user 
in this example can have 40 (decimal). 

DB Maximum number of deferred batch 

jobs the user can have in the system at 
one time (refer to section 9). In this 
example, the user can have 10 (deci- 
mal). 

FC Maximum number of permanent files 

the user can have. The example speci- 
fies SYSTEM, which means the installa- 
tion will determine this value. 



60436300 A 



C-1 



Field 
CS 



FS 

PA 

RO 
PX 

TT 



TC 
IS 

MS 
DF 
CC 

OF 
CP 
LP 



Description 

Maximam number of PRUs available for 
indirect-access permanent files. A 
PRU is a physical record unit which on 
mass stOTage is 640 6-bit characters. 
This example specifies 32768 decimal. 

Maximum number of PRUs available for 
any indirect-access permanent file. In 
this example, this is determined by the 
installation. 

Refers to ODD or EVEN parity in 
connection with terminal usage. In this 
example, it is EVEN. 

Rubout characters used to delay 
carriage return at a torminaL 

Specifies full- or half-duplex trans- 
mission mode tor a terminaL 

Specifies type of terminal available to 
the user. TTY is ASCII with standard 
print. A corr^pondence code terminal 
with standard print is COR; a corre- 
spondence code terminal with APL print 
is CORAPL. 

Character set to be used by a time- 
sharing terminaL This is either STAN- 
DARD (64-character) or ASCII (128- 
character). 

Initial subsystem for a time-sharing 
terminal. This is the subsystem that 
will be in effect when the user does not 
specify cme. Possible values are NULL, 
BASIC, FTN, EXECUTE, or BATCH. 

Maximum number of mass storage PRUs 
the user may additionally allocate via 
his job. The user in this example can 
allocate an additional 12800 PRUs. 

Maximum number of messages the user 
can issue to the dayflle. Refer to 
section 11 of the NOS Reference 
Manual, Volume 2. 

Maximum number of batch control 
statements the user can have in his job. 
The user in this example can have 464 
(decimal) statements in his control 
statement record. 

Maximum number of files the user can 
dispose to output. 

Maximum number of cards that can be 
punched from the user's punch file. 

Maximum number of lines a user's job 
may print. The value 31232 in this 
example is decimaL 



Field Description 

EC The maximum number of extended core 

memory words the user may request if 
the installation is using ECS (extended 
core storage). >««» 

SL The maximum number of SRUs (system 

resource unit) the user is allowed for 
each job. The SRU is an accounting 
value which the system determines by 
formula. 

CN Charge number to which the user is 

assigned. 

PN Project number to which the user is 

assigned. 

DS Maximum number of PRUs available to 

the user for any direct access 
permanent file. 

AW Access word which specifies the user's 

access options within the system. This 
is a 60-bit word. When a bit is set, it 
indicates an associated option is 
avfljlable. At ^^resent 13 cations are 
defined. These are read from right to 
left. The access word is displayed in 
octal. In this example, the octal value 
415 gives the following bit representa- 
tion. 



9 

\ 



100 001 101 

This indicates options 1, 3, 4, and 9 are 
in effect. The following options are of 
interest to the user of this guide. 

Option Specification 

1 User can change his pass- 

word. 

3 User is allowed to create 
direct access files. 

4 User is allowed to create 
indirect access Hies. 

7 User may request nonallo- 
catable devices (that is, 
magnetic tape units). 

8 User is allowed to access 
the system without charge 
or project numbers. 

9 User can define, save, and 
replace files on auxiliary 
devices. 
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NOS STANDARD CHARACTER SET 



■1 ibK 





CDC 
GRAPHIC 


ASCII 

GRAPHIC 

SUBSET 


DISPLAY 
CODE 


HOLLERITH 

PUNCH 

(026) 


EXTERNAL 

BCD 

CODE 


ASCII 
PUNCH 
(0291 


ASCII 
CODE 




:t 


; 


oot 


8-2 


00 


8-2 


3A 




A 


A 


01 


12-1 


61 


12-1 


4! 




B 


B 


02 


12-2 


62 


!2-2 


42 




C 


C 


03 


12-3 


63 


12-3 


43 




D 


D 


04 


12-4 


64 


12-4 


44 




E 


E 


05 


12-5 


65 


12-5 


45 




F 


F 


06 


12-6 


66 


J2-6 


46 




G 


G 


07 


12-7 


67 


12-7 


47 




H 


H 


10 


12-8 


70 


12-8 


48 




1 


1 


1 1 


12-9 


71 


12-9 


49 




J 


J 


12 


ll-l 


41 


ll-l 


4A 




K 


K 


13 


n-2 


42 


11-2 


4B 




L 


L 


14 


11-3 


43 


11-3 


4C 




M 


M 


15 


11-4 


44 


11-4 


4D 




N 


N 


16 


11-5 


45 


11-5 


4E 










17 


11-6 


46 


11-6 


4F 




P 


P 


20 


11-7 


47 


li-7 


50 







Q 


21 


11-8 


50 


11-8 


51 


!■ .£ J 


R 


R 


22 


11-9 


51 


11-9 


52 


1-5 !-rr: 


S 


S 


23 


0-2 


22 


0-2 


53 




T. 


T 


24 


0-3 


23 


0-3 


54 




U 


U 


25 


0-4 


24 


0-4 


55 




V 


V 


26 


0-5 


25 


0-5 


56 




w 


w 


27 


0-6 


26 


0-6 


57 




X 


X 


30 


0-7 


27 


0-7 


58 




Y 


Y 


31 


0-8 


30 


0-8 


59 




z 


z 


32 


0-9 


31 


0-9 


5A 










33 





12 





30 




1 


1 


34 


1 


01 


1 


3J 




2 


2 


35 


2 


02 


2 


32 




3 


3 


36 


3 


03 


3 


33 




4 


4 


37 


4 


04 


4 


34 




5 


5 


40 


5 


05 


5 


35 
















3AEI3A 



1 TWELVE OR MORE ZERO BITS AT THE END OF A 60- BIT WORD ARE 
INTERPRETED AS END-OF-LINE MARK RATHER THAN TWO COLONS. 
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ASCII 




HOLLERITH 


EXTERNAL 


ASCII 




CDC 


GRAPHIC 


DISPLAY 


PUNCH 


BCD 


PUNCH 


ASCII 


GRAPHIC 


SUBSET 


CODE 


(026) 


CODE 


(029) 


CODE 


6 


6 


41 


6 


06 


6 


36 ' 


7 


7 


42 


7 


07 


7 


37 


8 


8 


43 


8 


10 


6 


38 


9 


9 


44 


9 


1 1 


9 


39 


+ 


+ ' 


45 


12 


60 


12-8-6 


2B 


"• 


— 


46 


II 


40 


1 1 


2D 


X 


X 


47 


1 1-8-4 


54 


11-8-4 


2A 


/ 


/ 


50 


0-1 


21 


0-1 


2F 


( 


( 


51 


0-8-4 


34 


12-8-5 


28 


) 


) 


52 


12-8-4 


74 


11-8-5 


29 


S 


$ 


53 


11-8-3 


53 


1 1-8-3 


24 


c 


■ 


54 


8-3 


13 


8-6 


3D 


BLANK 


BLANK 


55 


NO PUNCH 


20 


NO PUNCH 


20 


.tCOMMA) 


.(COMMA) 


56 


0-8-3 


33 


0-8-3 


2C 


.(PERIOD) 


.(PERIOD) 


57 


12-8-3 


73 


12-8-3 


2E 


s 


'# 


60 


0-8-6 


36 


a-3 


23 


c 


c 


61 


8-7 


17 


12-8-2 


56 


] 


D 


62 


0-8-2 


32 


11-8-2 


50 


%t 


% 


63 


8-6 


16 


0-8-4 


25 


9* 


" (QUOTE) 


64 


8-4 


14 


8-7 


22 


— 


_(UI«)ERLINE) 


65 


0-8-5 


35 


0-8-5 


5F 


V 


! 


66 


ll-O 


52 


12-8-7 


21 


A 


a 


67 


0-8-7 


37 


12 


26 


f 


'(APOSTROPHE) 


70 


11-8-5 


55 


8-5 


27 


* 


? 


71 


11-8-6 


56 


0-8-7 


3F 


< 


< 


72 


12-0 


72 


12-8-4 


3C 


> 


> 


73 


1 1-8-7 


57 


0-8-6 


3E 


< 





74 


8-5 


15 


8-4 


40 


> 


\ 


75 


12-8-5 


75 


0-8-2 


5C 


-> 


-~ (CIRCUMFLEX) 


76 


12-8-6 


76 


11-8-7 


5E 


: (SEMICOLON] 


; (SEMICOLON) 


77 


12-8-7 


77 


11-8-6 


3B 



3MC OH 

t IN INSTALLATIONS USING THE CDC 63 -GRAPHIC SET, DISPLAY CODE 00 HAS NO ASSOCIATED 
GRAPHIC OR HOLLERITH CODE; DISPLAY CODE 63 IS THE COLON (8-2 PUNCH). THE 
SELECTION OF THE 63- OR 64-CHARACTER SET FOR TAPES IS AN INSTALLATION OPTION. 
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OPERATORS 



UOdA f 
3C0D i 



3e ! 

The following : operators form expressions in the majw 
higher-level languages and the NOS control language 
statements. 



ARItHMETtC OPERATORS 

Character Operation 



+ 


Addition 


- 


Subtraction 


* 


Multiplication 


••or } 


Ejcponentiation 


leading - 


Negation 


leadii^ + 


Ignored 



These characters are the same for prints and terminal 
except that { on a printer is ' (apostrophe) on a terminaL 

RELATIONAL OPERATORS 



Prints! 
(CDC Gr^iWc)' 


Terminal 

(Ascn) 


Alphabetic 
Symbol 


Meaning 






IT 


.EQ. 
.NE. 


Equal to 
Not equal to 


< 


■■■ - I 


< 


.LT. 


Less than 


> 




> 


.GT. 


GreatCT than 


< 




@ 


.LE. 


Less than or 
equal 


> 




/ 


.GE. 


Greater than 
or equal 



BOOLEAN OPERATORS 



Printer 
(CDC Graphic) 


Terminal 
(ASCn) 


Alphabetic 
Symbol 


Meaning 


s 


# 


.EQV. 


Equivalence 


V 


t 


.OR. 


Inclusive OR 


A 


& 


•AND. 


AND 


i 


1 


.EOR. 


Exclusive OR 


"1 


A 


.NOT. 


Complement 



EVALUATION OF EXPRESSIONS 

Exfa-essions are evaluated acceding to the following 
hierarchy. 



1. Exponentiation 

2. Multiplication, division 

3. Addition, subtraction, negation 

4. Relations 

5. Complement 

6. AND 

7. Inclusive OR 

8. Exclusive OR, equivalence 
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INDEX 



AESR B-l 

Alternate access of permanent Hies 5-4 

APPEND control statement 5-2 

Arithmetic operatc»rs E-1 

ATTACH control statement 5-4 



Backward positionii^ statements 4-4 
Batch 

Conv^sational 3-1 

Deferred 3-1 

Local 3-1 

Remote 3-1 
Batch input from a terminal 9-1 
Batch jobs 3-1 
BKSP control statement 4-4 
Blocks, tape 8-2 
Boolean bperat<»fs E-1 



CALL control statement 6-3 
CATLIST control statement 6-3 
CHANGE control statement 5-6 
Character »t, NOS D-1 
CHARGE control statement 3-4 
Coded copy statements 4-2 
Comments, control statement record 3-4 
Control language 6-1 
Control language statements 

CALL 6-3 

DISPLAY 6-2 

GOTO 6-2 

IF 6-3 

SET 6-1 
Control statement format 3-2 
Control aatement record 3-3 
Control statements 

APPEND 5-2 

ATTACH 5-4 

BAaC 3-5,7 

BKSP 4-4 

QATLIST 5-6 

CHANGE 5-6 

CHARGE 3-4 

COBOL 3-5,7 

COBOL5 3-5,7 

COPYBF 4-1 

COPYBR 4-1 

COPYCF 4-2 

COPYCR 4-2 

COPYEI 4-1 

COPYSBF 4-2 

DAYFILE 9-3 

DEFINE 5-3 

EXIT 7-1 

ENQUIRE 9-3 

FTN 3-5,7 

GET 5-2 

job 3-3 



LABEL 

Ifn 3-6 

LIMITS 

NOEXIT 

ONEXrr 

PDRGE 

REPLACE 

RESOURC 



8-2 



C-1 

7-1 

7-1 

5-4 
5-2 
8-3 



REWIND 4-5 

ROUTE 9-5 

SAVE 5-1 

SKIPEI 4-4 

SKIPF 4-4 

SKIPFB 4-4 

SKIPR 4-4 

SUBMIT 9-2 

USER 3-3 

VERIFY 4-3 
Conversational batch 3-1; 9-4 
Copy statonents 

Binary 4-1 

Coded 4-2 
COPYBF control statement 4-1 
COPYBR control statement 4-1 
COPYCF control statement 4-2 
COPYCR control statement 4-2 
COPYEI control statement 4-1 
COPYSBF control statement 4-2 



DayfUe B-l 

DAYFILE control statement 9-3 

Defenred batch 3-1; 9-1 

DEFINE statwnent 5-3 

Delimiters 2-1 

Denaty, tape 8-1 

Direct access permanent file 5-3 

Directives, reformatting 9-1 

DISPLAY control statement 6-2 



End-of-fUe CEOF) 2-3 

aid-of-information (EOI) 2-3 

End-of-record (EOR) 2-1 

ENQUIRE control statement 9-3 

EOF 2-3 

EOI 2-3 

EOR 2-1 

Error ccHitrol 7-1 

Error mess^es, tape 8-4 

EXIT control statement 7-1 



File 



INPUT 2-3 
Local 2-3 
OUTPUT 2-3 
Permanent 2-3; 5-1 
Tape 8-1 
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FILE function 6-1 

FUes, general 2-1 

FUe positioning statements 4-4 

Format, control statement 3-2 



GET control statement 5-2 

GOTO control language statement 6-2 



IF control lat^age statement 6-3 
Indirect access permanent files 5-1 
Input flle 2-3 



Job control statement 3-3 
Job structure, batch 3-1 



LABEL control statement 8-2 

Labels, tape 8-2 

LIMITS control statement C-1 

Listing permanoit files 5-6 

Local batch 3-1 

Local files 2-3 



NOEXrr control statement 7-1 



ONEXTT control statement 
Operators E-1 
Output nie 2-3 



7-1 



Parity, tape 8-1 
Permanent Hies 

Alternate access 5-4 

Direct access 5-3 

Indirect access 5-1 

Listing 5-6 

Purging S-4 
Portioning statements 

Backward 4-4 

Forward 4-4 
Programs 3-5 

PURGE control statement S-4 
Purging permanent files S-4 



Recording mode, tape 8-1 

Reformatting dirsctivss 9-1 

Relational operators £-1 

Remote batch 3-1 

REPLACE control statement 5-2 ' JMJV&V 

RESOURC control statement 3-3 

Resources, user C-1 

REWIND control statement 4-5 

ROUTE control statement 9-5 



SAVE control statement 5-1 

SET control language statement 6-1 

SKIPEI control ^atement 4-4 

SKIPF control statement 4-4 

SKIPFB control statement 4-4 

SKIPR conteol statement 4-4 

Statements 

Control (refer to control statements) 
Control language (refer to control 
language statements) 

SUBMIT control statement 9-2 



Tape error messages 8-4 
Tape files 8-1 
Tape format 8-2 

Tape tracks 8-1 
Twminal, batch iapal 9-1 



UCLP B-1 
UEAD B-1 
UECP B-1 
UEMS B-1 
OEPF B-1 
USER control statement 3-3 



VERIFY control statement 4-3 
Volume, tape 8-2 
Volume serial number (VSN) 8-2 
VSN 8-2 
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